[Bug c++/63140] New: wrong code generation probably due to optimization problem

[Bug c++/63140] New: wrong code generation probably due to optimization problem

[gcc at boomerangsworld dot de]

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

[gcc at boomerangsworld dot de]

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=33436&action=edit
(gzipped) preprocessed input file

[Bug c++/63140] wrong code generation probably due to optimization problem

[gcc at boomerangsworld dot de]

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.

[Bug c++/63140] wrong code generation probably due to optimization problem

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
You might want to try -fsanitize=undefined and/or -fno-strict-overflow as it
sounds like you may be invoking undefined behavior.

[Bug c++/63140] wrong code generation probably due to optimization problem

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or -fno-aggressive-loop-optimizations.  From your description it is hard to
figure what exactly to look for in the assembly, so e.g. bisecting compiler
where it stopped working is not easy.

[Bug c++/63140] wrong code generation probably due to optimization problem

[gcc at boomerangsworld dot de]

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is a git mirror of the svn repo.
Anyway, -fsanitize=undefined enables -fno-delete-null-pointer-checks, perhaps
you could try that option alone if it makes a difference.

[Bug c++/63140] wrong code generation probably due to optimization problem

[gcc at boomerangsworld dot de]

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=33442&action=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

[gcc at boomerangsworld dot de]

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=33443&action=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

[gcc at boomerangsworld dot de]

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=33444&action=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

[gcc at boomerangsworld dot de]

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=33445&action=edit
build

build script used to create executable test program

[Bug c++/63140] wrong code generation probably due to optimization problem

[gcc at boomerangsworld dot de]

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] wrong code generation probably due to optimization problem

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With that reduced testcase, I've bisected it to r208831, before inlining pass
there are no differences, and starting with r208831 the inliner changes
3 calls to __builtin_unreachable - __dynamic_cast, AWindow2::isParent and
fwrite.  Haven't yet looked why the inliner considers those unreachable, if
there is some undefined behavior that makes those unreachable, or something
else.
Honza?

[Bug c++/63140] wrong code generation probably due to optimization problem

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63140

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This might be fixed already just it was not marked as a regression.