https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140
Bug ID: 63140 Summary: wrong code generation probably due to optimization problem Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at boomerangsworld dot de A user of a tool of mine reported a strange endless loop in a code piece which could not behave in such a way. The bug always occured in the same method when using gcc 4.9 with O2 optimization. In this method, another method has been inlined by g++. If inlining of this method is suppressed, the code works again as expected. During the search of the cause of this problem I started looking at the assembler output of the compiler and identified some wrong code piece. Unfortunately I don't have a simple example triggering the problem, removing too much code or even add debug printf at some points will make the problem go away. So as for now, I stick with the attached example. If necessary, I can spend more time trying to minimize the example. The problem is within the two methods in file aguix.cc: The method "msgHandler" calls ReactMessage in (original) line 124, which will be inlined by gcc. The actual problem is in the result of this inlining, as the code for line 161 is incomplete and unconditionally continues at line 108. I paste the corresponding generated assembler code here: .L93: .LBB121: .LBB113: .LBB108: .LBB104: .LBB99: .loc 1 161 0 testq %r14, %r14 je .L58 movq (%rdi), %rax call *128(%rax) .LVL79: .p2align 4,,10 .p2align 3 .L92: .LBE99: .LBE104: .LBE108: .LBE113: .LBE121: .loc 1 108 0 discriminator 1 movl $5, %edi call _Z8waittimem Using the output of gcc 4.8 as comparison, the "call *128(%rax)" should corresponds to "win->getWindow()" but the rest of the expression is not evaluated. Then it directly continues calling "waittime". This results in an endless loop from line 108 in msgHandler to line 124 and back to 108 (for some input values of the msgHandler method). The problem occurs with gcc 4.9.1, and I have also tested the latest 4.9 snapshot gcc-4.9-20140827. It does not occur in gcc 4.8.1. Here are the exact specs: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/ralf/programs/gcc-4.9-20140827/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/ralf/programs/gcc-4.9-20140827 --enable-languages=c,c++ Thread model: posix gcc version 4.9.2 20140827 (prerelease) (GCC) The command line used is: g++ -DHAVE_CONFIG_H -I. -D_REENTRANT -I/home/ralf/local/include -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -g -O2 -std=c++11 -I/usr/include/freetype2 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Wall -MT aguix.o -MD -MP -MF .deps/aguix.Tpo -c -o aguix.o aguix.cc -save-temps The user originally reporting this bug to me mentioned that this problem does not occur in 32-bit target but I don't know if it really does not occur or just differently with not so obvious effects.