[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #8 from Uroš Bizjak --- (In reply to Sebastiano Vigna from comment #0) > The loop commented as "problematic loop" is compiled (with -O3) as > > xorl%eax, %eax # i > > That is, the loop index i is in %rax, but only the lower half is zeroed at > the start of the loop. When we enter the loop with a large (>32-bit) value, > the loop never ends. This happens already with -O1. We had to #pragma the > function to -O0 to make it work. If you are referring to the xorl insn above, then rest assured that it zeroes the whole 64bit register. Your bug is elsewhere.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #7 from Sebastiano Vigna --- I tried also with -fsanitize=address. No problems reported. Bug not showing up. A classical heisenbug.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #6 from Sebastiano Vigna --- I forgot an important aspect: with -fsanitize=undefined the optimization bug does not show up. The instrumentation perturbs the code enough to make it go away.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #5 from Sebastiano Vigna --- Fantastic tool! I didn't know about it. But it doesn't fire. There is no undefined behaviour in that code--it's just that the optimizer at -O1 does something wrong. I tried a binary search over the single options induced by -O1, but it turns out it's a combination of things--when I split the options in two half, the problem did not show up with either half. The code is 30-40 lines of assembly--I guess someone proficient with the output of the compiler could easily spot what's going wrong.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #4 from Richard Biener --- You can try -fsanitize=undefined and see if it fires.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #3 from Sebastiano Vigna --- As an additional information: we printed b->num_lines - 1 - n just before the loop, and everything is fine--we get there with the current value both with -O0 and -O1. But we -O1 we never exit the loop.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #2 from Sebastiano Vigna --- Er... it's perfectly possible. My knowledge of x64 assembly is rudimentary, but I wanted to try a diagnosis. What is definitely true is that at -O0 we enter and exit the loop as it should happen, and at -O1 we never exit the loop. For the time being we are #pragma'ing the function to remove optimizations.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #1 from Andrew Pinski --- I suspect there is an alias violation here rather what is described. In x86_64, almost all of the instructions which act on 32bit half of the registers will zero extend. That includes xorl.
