When I compile the attached source file, the s2_multiway_merge function gets apparently miscompiled. The do loop near the end of this function loses both of its terminating conditions and it is compiled to: .L101: addl $1, %esi .L53: movl -76(%ebp), %edi movl -92(%ebp), %eax movl -96(%ebp), %edx movl -32(%ebp), %ecx movl -36(%ebp), %ebx movl %edi, -4(%eax,%esi,4) movl -52(%ebp), %eax movl -100(%ebp), %edi movl %ecx, -4(%edx,%esi,4) movl -40(%ebp), %edx movl %eax, -4(%edi,%esi,4) movl $-1, (%edx) .L88: shrl %ebx je .L101 [... the s2_update_tree loop got inlined here, this test is its correct terminating condition ...] It seems that gcc thinks that `i' never changes in the loop, so it has optimized out every expression which depends in its value. I apologize for submitting a large source file, but the problem appears to be very chaotic and even removing parts of the source which are not referenced anywhere (see for example the block with the MAGIC comment attached) makes the problem disappear. Compilation command: gcc-4.2.1 -v -std=gnu99 -O2 -S xxx.c -Wunused -fgnu89-inline Output: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/opt/gcc-4.2.1 --enable-bootstrap Thread model: posix gcc version 4.2.1 /opt/gcc-4.2.1/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1 -quiet -v xxx.c -quiet -dumpbase xxx.c -mtune=generic -auxbase xxx -O2 -Wunused -std=gnu99 -version -fgnu89-inline -o xxx.s ignoring nonexistent directory "/opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /opt/gcc-4.2.1/include /opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/include /usr/include End of search list. GNU C version 4.2.1 (i686-pc-linux-gnu) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9831b30df15d36dc669e016cd6c4ba43
Created attachment 14146 [details] Source file triggering the problem
Can I do anything to help catch the bug?
Try with a recent GCC 4.2 version - GCC 4.2.4 is available. Also try GCC 4.3.1. Try to reduce the testcase or at least make it executable and arrange for it to abort () whenever the problem appears.
This looks like it was working correctly in GCC 4.4.7. It does look like it is broken in GCC 4.1.2 though. I suspect it was fixed by r127629 as -fno-strict-aliasing in GCC 4.1.2 also causes the correct code. So going to close it was fixed for 4.4.0 and link it to the ones which were known to be fixed by r127629 .