[Bug c++/46317] New: Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[Bug c++/46317] New: Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

           Summary: Incorrect construction vtable on ARM in case of
                    diamond shaped virtual inheritance
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: end3er@gmail.com


Created attachment 22295
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22295
Code that triggers the issue on ARM

This problem appears on ARM (not x86), with -O > 0.

The register R1 holding the pointer to the construction vtable for the
Parent-in-Child is actually pointing to the wrong Parent-in-Child vtable:

Let's assume we have a virtual base class A, two derived class B and C
virtually inheriting from A and a final class D derived virtually from B and
normally from C.

When instantiating D, the CTOR for B is called with R1 pointing to the
construction vtable for B-in-D instead of the one for C-in-D, which thus make
the program crash since it tries to access an uninitialized element of the
vtable for B when trying to access elements in C. 

A work-around for this issue is to compile with -fno-toplevel-reorder. It fixes
the problem for all optimizations level

This issue seems to be linked to #41354.

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-11-05 16:55:29 UTC ---
Does -fno-tree-sink fixes the issue?

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

--- Comment #2 from end3er at gmail dot com 2010-11-05 17:06:49 UTC ---
(In reply to comment #1)
> Does -fno-tree-sink fixes the issue?

No it doesn't. The only flags that works are:
-O0 or
-fno-inline or
-fno-unit-at-a-time or
-fno-toplevel-reorder

I can also make it work more or less by deactivating a certain number of
optimisation flag, but the output code does not really work... (I have tried
something like 58 different flags...)

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[ibolton at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

Ian Bolton <ibolton at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.01.28 10:19:03
                 CC|                            |ibolton at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #3 from Ian Bolton <ibolton at gcc dot gnu.org> 2011-01-28 10:19:03 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Does -fno-tree-sink fixes the issue?
> 
> No it doesn't. The only flags that works are:
> -O0 or
> -fno-inline or
> -fno-unit-at-a-time or
> -fno-toplevel-reorder
> 
> I can also make it work more or less by deactivating a certain number of
> optimisation flag, but the output code does not really work... (I have tried
> something like 58 different flags...)

Out of interest, did you try any newer releases of gcc?

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

--- Comment #4 from end3er at gmail dot com 2011-01-28 21:04:45 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Does -fno-tree-sink fixes the issue?
> > 
> > No it doesn't. The only flags that works are:
> > -O0 or
> > -fno-inline or
> > -fno-unit-at-a-time or
> > -fno-toplevel-reorder
> > 
> > I can also make it work more or less by deactivating a certain number of
> > optimisation flag, but the output code does not really work... (I have tried
> > something like 58 different flags...)
> 
> Out of interest, did you try any newer releases of gcc?

I finally took the time to compile gcc-4.5, and the issue is still there:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-c++
Target: arm-none-eabi
Configured with: ../configure --prefix=/opt/gcc-4.5/arm-none-eabi
--target=arm-none-eabi --enable-interwork --enable-multilib
--enable-languages=c,c++ --with-newlib --disable-nls --disable-shared
--disable-threads --with-gnu-as --with-gnu-ld
--with-gmp=/home/build/gcc-4.5_arm/gmp --with-mpfr=/home/build/gcc-4.5_arm/mpfr
--with-mpc=/home/build/gcc-4.5_arm/mpc
Thread model: single
gcc version 4.5.0 (GCC)


00008268 <D::D(int)>:
    8268:       e92d4038        push    {r3, r4, r5, lr}
    826c:       e1a04000        mov     r4, r0
    8270:       e1a02001        mov     r2, r1
    8274:       e1a03000        mov     r3, r0
    8278:       e59f103c        ldr     r1, [pc, #60]   ; 82bc <D::D(int)+0x54>
    827c:       e4831008        str     r1, [r3], #8
    8280:       e59f5038        ldr     r5, [pc, #56]   ; 82c0 <D::D(int)+0x58>
    8284:       e595102c        ldr     r1, [r5, #44]   ; 0x2c
    8288:       e5801008        str     r1, [r0, #8]
    828c:       e5111010        ldr     r1, [r1, #-16]
    8290:       e595c030        ldr     ip, [r5, #48]   ; 0x30
    8294:       e783c001        str     ip, [r3, r1]
    8298:       e285101c        add     r1, r5, #28
    829c:       ebffffca        bl      81cc <C::C(int)>

...

    82bc:       0001d3e8
    82c0:       0001d418
...
r1 = [0x1d418, #44]
   1d444:       0001d4b0
...
r1 = 0x1d4b0, #-16
0001d4a0 <construction vtable for B-in-D>:
   1d4a0:       fffffff8
...
000081cc <C::C(int)>:
    81cc:       e591c000        ldr     ip, [r1]


the correct r1 value should be:

0001d488 <construction vtable for C-in-D>:
        ...
   1d494:       0001d4f8        strdeq  sp, [r1], -r8
   1d498:       000081b8        undefined instruction 0x000081b8
   1d49c:       00000000        andeq   r0, r0, r0


When compiling with -O0, r1 is set to a correct address belonging to C-in-D:

00008448 <D::D(int)>:
    8448:       e92d4800        push    {fp, lr}
    844c:       e28db004        add     fp, sp, #4
    8450:       e24dd008        sub     sp, sp, #8
    8454:       e50b0008        str     r0, [fp, #-8]
    8458:       e50b100c        str     r1, [fp, #-12]
    845c:       e51b3008        ldr     r3, [fp, #-8]
    8460:       e1a00003        mov     r0, r3
    8464:       eb000100        bl      886c <A::A()>
    8468:       e51b3008        ldr     r3, [fp, #-8]
    846c:       e2832008        add     r2, r3, #8
    8470:       e59f3070        ldr     r3, [pc, #112]  ; 84e8 <D::D(int)+0xa0>
    8474:       e2833014        add     r3, r3, #20
    8478:       e1a00002        mov     r0, r2
    847c:       e1a01003        mov     r1, r3
    8480:       eb000106        bl      88a0 <B::B()>
    8484:       e51b2008        ldr     r2, [fp, #-8]
    8488:       e59f3058        ldr     r3, [pc, #88]   ; 84e8 <D::D(int)+0xa0>
    848c:       e2833004        add     r3, r3, #4
    8490:       e1a00002        mov     r0, r2
    8494:       e1a01003        mov     r1, r3
    8498:       e51b200c        ldr     r2, [fp, #-12]
    849c:       ebffff45        bl      81b8 <C::C(int)>
...
    84e8:       0001d950
...
0001d950, #4
    1d954:       0001d980
...
0001d970 <construction vtable for C-in-D>:
        ...
   1d97c:       0001d9f4        strdeq  sp, [r1], -r4
   1d980:       00008374        andeq   r8, r0, r4, ror r3

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

end3er at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |end3er at gmail dot com

--- Comment #5 from end3er at gmail dot com 2011-01-28 21:15:19 UTC ---
oops, I missed  some lines from the C CTOR:

000081cc <C::C(int)>:
    81cc:       e591c000        ldr     ip, [r1]
    81d0:       e580c000        str     ip, [r0]
    81d4:       e51cc010        ldr     ip, [ip, #-16]

 ([r1] is equal to [0x1d4a0] = 0xfffffff8 instead of [0x1d498]=0x81b8 which is
mapped)

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #6 from Mikael Pettersson <mikpe at it dot uu.se> 2011-01-29 17:40:42 UTC ---
This test case works for me on armv5tel-linux-gnueabi with gcc 4.4.5, 4.5.2,
and 4.6-20110122.

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

end3er at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.5.0                       |4.2.1

--- Comment #7 from end3er at gmail dot com 2011-01-30 17:35:32 UTC ---
(In reply to comment #6)
> This test case works for me on armv5tel-linux-gnueabi with gcc 4.4.5, 4.5.2,
> and 4.6-20110122.


Oops, you are right actually, I missed one line in my static analysis (I didn't
have an ARM target to live test...):
    8298:       e285101c        add     r1, r5, #28
This line actually correctly sets r1 to <construction vtable for C-in-D>+0x10
when compiling with GCC 4.5.0

So the bug is actually only seen with GCC 4.2.1

Sorry for the false positive...

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |rearnsha at gcc dot gnu.org
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> 2011-04-18 16:10:01 UTC ---
gcc-4.2 is no-longer being maintained.  Closing as fixed.