On 11/5/10, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > andrew wiggin <end3er@xxxxxxxxx> 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