Different results for 'clang++ huh.cpp' and 'clang++ -O3 huh.cpp' - Codegen??

[llvmbot]

Bugzilla Link	11375
Resolution	FIXED
Resolved on	Nov 17, 2011 22:25
Version	trunk
OS	MacOS X
Blocks	llvm/llvm-bugzilla-archive#11388
Attachments	Sample program demonstrating the bug
Reporter	LLVM Bugzilla Contributor
CC	@atrick,@DougGregor,@efriedma-quic

Extended Description

When compiling the attached code (huh.cpp), I get different results when specifying -O3 vs. -O0

$ clang++ -O0 huh.cpp && ./a.out

Test fail on line 111 1 == 0

Returning: 5, 14
Returning: 5, 14
Returning: 5, 14
Returning: 7, 7
Returning: 7, 11
Returning: 5, 15
Returning: 5, 15
Returning: 5, 15
Returning: 9, 9
Returning: 9, 12

$ clang++ -O3 huh.cpp && ./a.out

Test fail on line 111 1 == 0

Returning: 5, 12
Returning: 7, 14
Returning: 5, 14
Returning: 7, 7
Returning: 7, 11
Returning: 5, 15
Returning: 5, 15
Returning: 5, 15
Returning: 9, 9
Returning: 9, 12

The first two lines are different!!
gcc gets the same results as -O0 (which I believe is correct).

Platform is x86, Darwin (Mac OS X 10.7.2)
Occurs on:

$ clang++ --version
clang version 3.1 (trunk 144534)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

-- and --

$ clang++ --version
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

[llvmbot]

assigned to @atrick

[efriedma-quic]

IR testcase (OSX)
Run -indvars over the attached to reproduce; looks like it's replacing a loop-computed value with its exit value, but computing the wrong value.

[efriedma-quic]

Bisect points to r127638, "Propagate SCEV no-wrap flags whenever possible." I haven't examined the testcase closely, so it's possible it's depending on undefined wrapping behavior.

[llvmbot]

Uncommenting the debugging output, I get (where output is marked with -->)

17: std::cout << "minmax: " << *min_element << ", " << *max_element
18: << ", next = " << *first << std::endl;
--> minmax: 5, 13, next = 14

19: ForwardIterator one = first;
20: if ( ++first == last ) { // one item left
21: std::cout << "One element = " << *one << std::endl;
--> One element = 12

if *first == 14, and then one = first, then *one should == 14, not 12 (which was it's value during the previous iteration of the loop)

[llvmbot]

For what it's worth, dragonegg produces the same results as clang.

[atrick]

For loops with multiple exits, if one of the loop tests is "icmp ne", and the loop counter jumps by > 1, and the loop exits via another loop test, then the exit value could be replaced with the wrong constant.

Fixed in r144746.

[atrick]

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