[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #5 from Ralf Hoffmann gcc at boomerangsworld dot de --- Thanks for the feedback, I am also suspecting I have some problem in my code regarding undefined behavior. What I do for testing is to compile my tool Worker (http://www.boomerangsworld.de/cms/worker/index.html, version 3.5.0) with make clean LDFLAGS=-fsanitize=undefined CPPFLAGS=-fsanitize=undefined ./configure make and then start the program (src/worker), click on top left A button for the about dialog and click on the down arrow to scroll down the option list. It then either works, or the process hangs in the endless loop. I tried to use -fsanitize=undefined and it actually makes a difference. There is no compiler output pointing out some problem and also no runtime output when reaching the test point mentioned above. But with this option, it behaves normally and the endless loop does not occur. When using the options -fno-strict-overflow or -fno-aggressive-loop-optimizations the problem still occurs. I would like to help bisecting the compiler if you could give me a hint where to start. As far as I see, there is no git repo which would make it easier.
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #7 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33442 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33442action=edit simplified example file 1 simple example containing the code piece which triggers the behavior
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #8 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33443 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33443action=edit aguixtest.cc file with helper functions, not related to the problem, but required to execute
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #9 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33444 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33444action=edit aguixtest.hh file with helper functions, not related to the problem, but required to execute
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #10 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33445 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33445action=edit build build script used to create executable test program
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #11 from Ralf Hoffmann gcc at boomerangsworld dot de --- I managed to create a standalone test program. Attachment aguix.cc contains the stripped down critical code segments. The two other files aguixtest.cc and aguixtest.hh are just to make a runnable binary. The attached script build can be used to create the binary. The expected output is: wait4mess2 called waittime2: 5 Worker: msg lock element lost! Worker: msg lock element lost! wait4mess2 called (this is what the binary does with gcc 4.8.1) while with gcc 4.9.1 it will loop forever: wait4mess2 called waittime2: 5 waittime2: 5 waittime2: 5 waittime2: 5 Compiled with -O1 instead of -O2 the example program crashes. Adding -fsanitize=undefined on the other hand will make it work again regardless of O1 or O2.
[Bug c++/63140] New: wrong code generation probably due to optimization problem
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.
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #1 from Ralf Hoffmann gcc at boomerangsworld dot de --- Created attachment 33436 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33436action=edit (gzipped) preprocessed input file
[Bug c++/63140] wrong code generation probably due to optimization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140 --- Comment #2 from Ralf Hoffmann gcc at boomerangsworld dot de --- Small update: The working 32 bit target was gcc 4.7, so it's not related to this bug.
