[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance
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)
8268 :
8268: e92d4038push{r3, r4, r5, lr}
826c: e1a04000mov r4, r0
8270: e1a02001mov r2, r1
8274: e1a03000mov r3, r0
8278: e59f103cldr r1, [pc, #60] ; 82bc
827c: e4831008str r1, [r3], #8
8280: e59f5038ldr r5, [pc, #56] ; 82c0
8284: e595102cldr r1, [r5, #44] ; 0x2c
8288: e5801008str r1, [r0, #8]
828c: e5111010ldr r1, [r1, #-16]
8290: e595c030ldr ip, [r5, #48] ; 0x30
8294: e783c001str ip, [r3, r1]
8298: e285101cadd r1, r5, #28
829c: ebcabl 81cc
...
82bc: 0001d3e8
82c0: 0001d418
...
r1 = [0x1d418, #44]
1d444: 0001d4b0
...
r1 = 0x1d4b0, #-16
0001d4a0 :
1d4a0: fff8
...
81cc :
81cc: e591c000ldr ip, [r1]
the correct r1 value should be:
0001d488 :
...
1d494: 0001d4f8strdeq sp, [r1], -r8
1d498: 81b8undefined instruction 0x81b8
1d49c: andeq r0, r0, r0
When compiling with -O0, r1 is set to a correct address belonging to C-in-D:
8448 :
8448: e92d4800push{fp, lr}
844c: e28db004add fp, sp, #4
8450: e24dd008sub sp, sp, #8
8454: e50b0008str r0, [fp, #-8]
8458: e50b100cstr r1, [fp, #-12]
845c: e51b3008ldr r3, [fp, #-8]
8460: e1a3mov r0, r3
8464: eb000100bl 886c
8468: e51b3008ldr r3, [fp, #-8]
846c: e2832008add r2, r3, #8
8470: e59f3070ldr r3, [pc, #112] ; 84e8
8474: e2833014add r3, r3, #20
8478: e1a2mov r0, r2
847c: e1a01003mov r1, r3
8480: eb000106bl 88a0
8484: e51b2008ldr r2, [fp, #-8]
8488: e59f3058ldr r3, [pc, #88] ; 84e8
848c: e2833004add r3, r3, #4
8490: e1a2mov r0, r2
8494: e1a01003mov r1, r3
8498: e51b200cldr r2, [fp, #-12]
849c: eb45bl 81b8
...
84e8: 0001d950
...
0001d950, #4
1d954: 0001d980
...
0001d970 :
...
1d97c: 0001d9f4strdeq sp, [r1], -r4
1d980: 8374andeq r8, r0, r4, ror r3
[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance
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: 81cc : 81cc: e591c000ldr ip, [r1] 81d0: e580c000str ip, [r0] 81d4: e51cc010ldr ip, [ip, #-16] ([r1] is equal to [0x1d4a0] = 0xfff8 instead of [0x1d498]=0x81b8 which is mapped)
[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance
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: e285101cadd r1, r5, #28 This line actually correctly sets r1 to +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] New: Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance
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: unassig...@gcc.gnu.org ReportedBy: end...@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
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...)
