As reported in this thread:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01798.html
This problem was reported by an ARM user and reproduced on arm-none-eabi, but
is not target-specific.
If the attached test program is compiled with -O1, it fails by incorrectly
calling a pure virtual method. What is happening is that tree-ssa-sink is
moving code from the inlined destructor for STUFF, in the first nested block,
into the second nested block, where it ends up after the code for the inlined
constructor for STUFF2. Then, cfgexpand comes along and decides that STUFF and
STUFF2 can share stack space because they are in disjoint lexical blocks. Thus
the sunk destructor statement for STUFF ends up trashing the vtable of STUFF2.
The test program appears to work correctly at -O2 only because
-fstrict-aliasing prevents cfgexpand from assigning STUFF and STUFF2 to the
same stack offset.
Per further discussion in the thread above, cfgexpand's stack layout should not
be using lexical block scoping information to determine when stack variables
may share storage, as GIMPLE lowering removes lexical scopes and promotes all
locals to function scope, and subsequent middle-end optimizations do not
preserve the lexical block structure. Since stack variable sharing is an
important optimization for some applications, some other form of lifetime
analysis is needed.
Apparently PR middle-end/32327 was another incarnation of this same problem,
but was closed without really addressing it.
--
Summary: tree-ssa-sink breaks stack layout
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sandra at codesourcery dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
