Re: Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[andrew wiggin <end3er at gmail dot com>]

On 11/5/10, Ian Lance Taylor <iant@google.com> wrote:
> andrew wiggin <end3er@gmail.com> writes:
>
>> I have recently met a segfault in a program I had to port from x86 to
>> ARMv7. After some investigation I managed to narrow it down to a few
>> C++ lines which when compiled with -O > 0 will always produce an
>> incorrect assembly on ARM.
>>
>> I am using GCC 4.2.1 for ARM.
>>
>> 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 from B and C.
>> When instantiating D, the CTOR for B is called with R1 pointing to the
>> construction vtable for C-in-D instead of the one for B-in-D, which
>> thus make the program crash since it tries to access an uninitialized
>> element of the vtable for C when trying to access elements in B. (I
>> hope it is clear enough).
>
> Your C++ code looks OK to me.  I guess the first thing I would recommend
> is trying a newer version of gcc to see if the bug has been fixed.
>

Thanks for your reply !
It is not that easy for me to test a newer version of GCC since I
don't have that much time to allocate on this problem. Thus my asking
on the ML ;)
However, I did test with the Apple gcc-4.2.1 for ARM, and the
resulting assembly is valid, without having to add any extra flag.
I tried comparing the output assembly for both compiler, and the code
generated with the Apple gcc is closer to the output assembly from gcc
with the flag -fno-toplevel-reorder... So I don't really know if they
fixed the issue or just removed some optimization code from GCC.


>> It seems to be related to bug:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41354 however the
>> -fno-tree-sink doesn't resolve the issue, so I am assuming that it is
>> not a duplicate.
>
> I would guess that it is the same underlying problem, though: a problem
> with alias analysis leading to invalid stack slot sharing.  That bug
> should be fixed in gcc 4.5.
>

That sound consistent. Do you think I should open a bug in the GCC
bugzilla and link it to this one for tracking purpose ?

> Ian
>

-- 
ender