Closed llvmbot closed 9 years ago
r222451 | mzolotukhin | 2014-11-20 21:19:55 +0100 (Thu, 20 Nov 2014) | 9 lines
Fix a trip-count overflow issue in LoopUnroll.
Currently LoopUnroll generates a prologue loop before the main loop body to execute first N%UnrollFactor iterations. Also, this loop is used if trip-count can overflow - it's determined by a runtime check.
Of course. I am reporting this to Apple. Thanks.
Unfortunately the bug remains in the latest compiler tools release from Apple.
We have no control over that; you should take this up with Apple.
Note that in the comments the reported version includes "based on LLVM 3.6.0svn". I took that to mean version 3.6. Is that not correct? Is it really version 3.5?
Yes, sorry about our version numbering scheme, it's a common source of confusion. 3.6.0svn means approximately "some point on svn trunk between when 3.5.0 branched and when 3.6.0 branched". For instance, right now, the latest release is 3.6.2, we've branched 3.7 but not yet released it, and svn trunk claims to be 3.8.0svn.
Unfortunately the bug remains in the latest compiler tools release from Apple.
Note that in the comments the reported version includes "based on LLVM 3.6.0svn". I took that to mean version 3.6. Is that not correct? Is it really version 3.5?
I can't reproduce this with trunk, nor 3.6, but it reproduces with 3.5. Looks like this has been fixed for a while. I remember we had (and fixed) a bug analyzing loops with an N bit induction variable that perform exactly 2^N iterations; that could be the bug you hit.
Extended Description
The C code below gives different results with -O0/-O1 vs. -O2/-O3. -O1 gives the correct result, whereas -O2 gives an incorrect result. See the comments in the code.
/* Example of a clang optimization bug. Mark Adler, August 8, 2015.
*/
include
include
/ bit vector of 1<<32 bits, initialized to all zeros / static uint64_t vec[1 << 26] = {0};
int main(void) { / set 47 of the bits. / vec[31415927] = UINT64_C(0xb9fe2f2fedf7ebbd);
}