The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in 32-bit mode. This is a regression from 4.8.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 4.9.0 20130915 (experimental) [trunk revision 202599] (GCC) $ gcc-trunk -m32 -O2 small.c $ a.out $ gcc-4.8 -m32 -O3 small.c $ a.out $ gcc-trunk -m32 -O3 small.c $ a.out Aborted (core dumped) $ --------------------------------------- char a, h; int b, d, e, g, j, k; volatile int c; short i; int main () { int m = i ^= 1; for (b = 0; b < 1; b++) { char o = m; g = k; j = j || c; if (a != o) for (; d < 1; d++) ; else { char *p = &h; *p = 1; for (; e; e++) ; } } if (h != 0) __builtin_abort(); return 0; }
Started with r202489.
Jakub, That doesn't make *any* sense. r202489 simply *avoids* doing any jump threading in certain cases. If that change is indeed the trigger, then the root cause is going to be a latent bug elsewhere.
-fdisable-tree-phicprop2 lets it pass (the dumps appear identical before and after this pass, but with verbose dumps we see some memory PHIs disappear) -fdisable-tree-cddce2 also lets it pass, with larger differences in the dumps.
Verified as a duplicate. *** This bug has been marked as a duplicate of bug 58418 ***