instcombine miscompilation

[edwintorok]

Bugzilla Link	3595
Resolution	FIXED
Resolved on	Nov 07, 2018 00:22
Version	unspecified
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#3596
Attachments	bugpoint-passinput.bc, Testcase to reproduce problem, preprocessed testcase, bugpoint-tonotoptimize.bc, bugpoint-tooptimize.bc
CC	@efriedma-quic,@nlewycky

Extended Description

Using SVN r64664 of clang to compile ClamAV, I get 1 error in 'make check' of ClamAV:

99%: Checks: 235, Failures: 1, Errors: 0
../../../clamav-devel/unit_tests/check_str.c:61:F:cli_unescape:test_unescape_hex:0: cli_unescape truncated
FAIL: check_clamav

Bugpoint has reduced this to be an instcombine bug.

Here's bugpoint's output:
*** Found miscompiling pass: -instcombine
Emitted bitcode to 'bugpoint-passinput.bc'

*** You can reproduce the problem with: opt bugpoint-passinput.bc -instcombine
Checking to see if the program is misoptimized when these functions are run through the pass: cli_unescape cli_hex2int output_utf8 main
Optimizing functions being tested: done.
Checking to see if the merged program executes correctly: yup.

*** The following functions are being miscompiled: cli_unescape cli_hex2int output_utf8 main
Extracted a loop from the breaking portion of the program.
Testing after loop extraction:
Optimizing functions being tested: done.
Checking to see if the merged program executes correctly: yup.
*** Loop extraction masked the problem. Undoing.
Checking to see if the program is misoptimized when all blocks are extracted.
Optimizing functions being tested: done.
Checking to see if the merged program executes correctly: yup.
Checking to see if the program is misoptimized when all but these 29 blocks are extracted: entry for.cond for.body if.then15 lor.lhs.false lor.lhs.false29 lor.lhs.false38 lor.lhs.false47 lor.lhs.false56 if.then65 ...
Optimizing functions being tested: done.
Checking to see if the merged program executes correctly: yup.
Outputting reduced bitcode files which expose the problem:
Non-optimized portion: Emitted bitcode to 'bugpoint-tonotoptimize.bc'
Portion that is input to optimizer: Emitted bitcode to 'bugpoint-tooptimize.bc'

[edwintorok]

assigned to @nlewycky

[efriedma-quic]

I can't reproduce on x86-32; perhaps an x86-64 specific bug?

(The bugpoint reduction is bogus; the one transformation instcombine does on the given bugpoint-tooptimize is obviously legal.)

[edwintorok]

I can't reproduce on x86-32; perhaps an x86-64 specific bug?

(The bugpoint reduction is bogus; the one transformation instcombine does on
the given bugpoint-tooptimize is obviously legal.)

Did you try to reproduce with bugpoint-passinput.bc?
http://llvm.org/bugs/attachment.cgi?id=2565

[efriedma-quic]

Yes, I tried it; I haven't gotten anything other than "OK" as output.

[nlewycky]

It reproduces for me with LLVM head on x86-32.

[nlewycky]

Instcombine is screwing up a 32-bit load from constant.

$ cat foo.ll
@.str1 = internal constant [4 x i8] c"\B5%8\00"

define i32 @​test() {
%rhsv = load i32* bitcast ([4 x i8]* @.str1 to i32*), align 1
ret i32 %rhsv
}
$ llvm-as < foo.ll | opt -instcombine | llvm-dis
; ModuleID = ''
@.str1 = internal constant [4 x i8] c"\B5%8\00", align 4 ; <[4 x i8]*> [#uses=0]

define i32 @​test() {
ret i32 -1255852032
}

That's the wrong answer. The right answer is 3679669. To check, try this C program:

$ cat x.c
const char x[4] = {0xb5, 0x25, 0x38, 0x00};

int main(void) {
printf("%d\n", (unsigned int)x);
printf("%x\n", (unsigned int)x);
}
$ gcc x.c -o x
x.c: In function ‘main’:
x.c:4: warning: incompatible implicit declaration of built-in function ‘printf’
$ ./x
3679669
3825b5
$ llvm-gcc x.c -o x -O2
x.c: In function ‘main’:
x.c:4: warning: incompatible implicit declaration of built-in function ‘printf’
$ ./x
-75
ffffffb5

Next step is to figure out why it's doing this wrong.

[nlewycky]

Fixed in r65246.

[edwintorok]

Fixed in r65246.

Thanks, this happens with 2.5prerelease2 too, should this patch be pulled into it?

[nlewycky]

Not unless it fixes a regression. I consider this patch very low risk though, so if it's an important regression for you, please email Tanya to ask. Keep in mind that we're very late in the release cycle for this sort of thing ...

[edwintorok]

Not unless it fixes a regression. I consider this patch very low risk though,
so if it's an important regression for you,

No, its not that important.
This only happens if clang compiles the original source code, llvm-gcc compiles it in a way that avoids this bug.
Since clang has not been released yet, I'm fine with having the fix in trunk only.

[lattner]

Very nice fix!

[edwintorok]

mentioned in issue llvm/llvm-bugzilla-archive#3596