public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/63140] New: wrong code generation probably due to optimization problem
@ 2014-09-02 15:51 gcc at boomerangsworld dot de
  2014-09-02 15:54 ` [Bug c++/63140] " gcc at boomerangsworld dot de
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: gcc at boomerangsworld dot de @ 2014-09-02 15:51 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-07-22 16:50 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-02 15:51 [Bug c++/63140] New: wrong code generation probably due to optimization problem gcc at boomerangsworld dot de
2014-09-02 15:54 ` [Bug c++/63140] " gcc at boomerangsworld dot de
2014-09-02 17:54 ` gcc at boomerangsworld dot de
2014-09-03  9:03 ` rguenth at gcc dot gnu.org
2014-09-03  9:45 ` jakub at gcc dot gnu.org
2014-09-03 10:30 ` gcc at boomerangsworld dot de
2014-09-03 12:12 ` jakub at gcc dot gnu.org
2014-09-03 12:57 ` gcc at boomerangsworld dot de
2014-09-03 12:59 ` gcc at boomerangsworld dot de
2014-09-03 13:00 ` gcc at boomerangsworld dot de
2014-09-03 13:01 ` gcc at boomerangsworld dot de
2014-09-03 13:05 ` gcc at boomerangsworld dot de
2014-09-03 16:35 ` jakub at gcc dot gnu.org
2021-07-22 16:50 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).