The current gcc trunk produces wrong code (that hangs) for the following testcase on x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes. This is a regression from 4.8.x. It might be related to 58143, but 58143 also fails for 4.8. $ gcc-trunk -v gcc version 4.9.0 20130822 (experimental) [trunk revision 201915] (GCC) $ gcc-4.8 -O3 reduced.c $ a.out $ gcc-trunk -O2 reduced.c $ a.out $ gcc-trunk -O3 reduced.c $ a.out ^C $ ------------------------------------------ int a, b, d, e, f, *g, h, i; volatile int c; char foo (unsigned char p) { return p + 1; } int bar () { for (h = 0; h < 3; h = foo (h)) { c; for (f = 0; f < 1; f++) { i = a && 0 < -2147483647 - h ? 0 : 1; if (e) for (; d;) b = 0; else g = 0; } } return 0; } int main () { bar (); return 0; }
I think this invokes undefined behavior in third iteration, when h is 2. Works with s/-2147483647/-2147483647L/.
But similar to 58143, because of short circuiting (since a == 0), the expression "0 < -2147483647 - h ? 0 : 1" shouldn't be evaluated at all, correct? Or maybe I'm mistaken? Thanks for looking into this Marek!
Yes, sorry. Loop invariant motion moves the condition here as well, I suppose (works with -fno-tree-loop-im). Thus confirmed.
OK, the latest patch from pr58143 seems to fix the deadlock here too.
Duplicate. *** This bug has been marked as a duplicate of bug 58143 ***