[Bug middle-end/39604] New: tree-ssa-sink breaks stack layout

[Bug middle-end/39604] New: tree-ssa-sink breaks stack layout

[sandra at codesourcery dot com]

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

[Bug middle-end/39604] tree-ssa-sink breaks stack layout

[sandra at codesourcery dot com]

------- Comment #1 from sandra at codesourcery dot com  2009-03-31 22:37 -------
Created an attachment (id=17573)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17573&action=view)
C++ test case sink-1.C


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |tree-optimization
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
           Keywords|                            |wrong-code
      Known to fail|                            |4.4.0
      Known to work|                            |3.4.0
            Summary|tree-ssa-sink breaks stack  |[4.3/4.4/4.5 Regression]
                   |layout                      |tree-ssa-sink breaks stack
                   |                            |layout
   Target Milestone|---                         |4.3.4


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-04-01 08:42:30
               date|                            |


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[matz at gcc dot gnu dot org]

------- Comment #2 from matz at gcc dot gnu dot org  2009-04-01 11:45 -------
The old stack slot sharing problem.  stack slot sharing really wants to
look at scopes to determine if stack variables can share the same space or
not (stack variables, not registers, those are all top-level).  But sometimes
tree transformations do fiddle also with stack variables (loads/stores) and
hence can move references to variables outside of their block tree.

The block tree either needs to be fixed up, or the stack slot sharing needs
to look at other information than block scopes to determine lifeness bounds.

Both of these things are probably best done in cfgexpand, and as I'm working
on expanding from SSA form I might try to do something here (though the
variables in question are exactly those which are _not_ in SSA form).


-- 

matz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at gcc dot gnu dot org


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2009-04-01 14:00 -------
Even for live range analysis of the vars that must go into stack the block info
needs to be used, otherwise once address of a stack var escapes, you'd have to
assume it is live almost till the end of the function (at least live on any
function calls that might see it through global state, or global ptr
dereferences etc.).  Using the block info, you can find out that:
  {
    char buf[10];
    foo (buf);
    bar ();
  }
  baz ();
in baz () call the buf var doesn't need to be live anymore.  At least short
term I think it would be best just to walk the function to be expanded, look at
all gimple_block BLOCKs referenced and note which originally non-overlapping
BLOCKs are indeed still non-overlapping after the tree passes and don't
consider originally non-overlapping BLOCKs during stack slot sharing decisions
if they are overlapping.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[matz at gcc dot gnu dot org]

------- Comment #4 from matz at gcc dot gnu dot org  2009-04-01 14:05 -------
Yes, that's my thought too.  Fixing the BLOCK_VARS when references to
variables show up in a block where they weren't before.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenther at suse dot de]

------- Comment #5 from rguenther at suse dot de  2009-04-01 14:10 -------
Subject: Re:  [4.3/4.4/4.5 Regression] tree-ssa-sink
 breaks stack layout

On Wed, 1 Apr 2009, jakub at gcc dot gnu dot org wrote:

> ------- Comment #3 from jakub at gcc dot gnu dot org  2009-04-01 14:00 -------
> Even for live range analysis of the vars that must go into stack the block info
> needs to be used, otherwise once address of a stack var escapes, you'd have to
> assume it is live almost till the end of the function (at least live on any
> function calls that might see it through global state, or global ptr
> dereferences etc.).  Using the block info, you can find out that:
>   {
>     char buf[10];
>     foo (buf);
>     bar ();
>   }
>   baz ();
> in baz () call the buf var doesn't need to be live anymore.  At least short
> term I think it would be best just to walk the function to be expanded, look at
> all gimple_block BLOCKs referenced and note which originally non-overlapping
> BLOCKs are indeed still non-overlapping after the tree passes and don't
> consider originally non-overlapping BLOCKs during stack slot sharing decisions
> if they are overlapping.

Note that once we use more precise alias information during RTL
optimizations (via alias exports patch) avoiding stack slot sharing
solely based on type-based conflicts will no longer be working.

Richard.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2009-04-01 14:15 -------
One would hope that with -fno-strict-aliasing we can still share the stack
slots even with alias export patch, otherwise the kernel people are going to be
extremely violent on us.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenther at suse dot de]

------- Comment #7 from rguenther at suse dot de  2009-04-01 14:29 -------
Subject: Re:  [4.3/4.4/4.5 Regression] tree-ssa-sink
 breaks stack layout

On Wed, 1 Apr 2009, jakub at gcc dot gnu dot org wrote:

> ------- Comment #6 from jakub at gcc dot gnu dot org  2009-04-01 14:15 -------
> One would hope that with -fno-strict-aliasing we can still share the stack
> slots even with alias export patch, otherwise the kernel people are going to be
> extremely violent on us.

I think it would be easier to fix scheduling to properly detect
the must-conflicts by noting down the stack slot partition used
in MEMs (and obviously if we end up having MEMs w/o an assigned
parition make that conflict with any other - this can then be
refined with PTA information from the alias export).

The same is true for gcse-sm - any other RTL pass that may
be a problem?

Richard.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[matz at gcc dot gnu dot org]

------- Comment #8 from matz at gcc dot gnu dot org  2009-04-01 14:47 -------
One other approach is to create new aliasing conflicts once we union
two stack partitions.  That would inhibit any invalid (after sharing)
transformations by RTL transformations downstream (when they look at only such
conflicts, i.e. TBAA).  If they also look at other disambiguation
possibilities then we indeed need to make the stack partition part of the IL 
and use it in the alias queries.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[sandra at codesourcery dot com]

------- Comment #9 from sandra at codesourcery dot com  2009-04-03 12:54 -------
After the merge of the alias_improvements branch to trunk, the test case no
longer compiles incorrectly at -O1.  Is this coincidence, or a real fix that
addresses the underlying problem?


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenther at suse dot de]

------- Comment #10 from rguenther at suse dot de  2009-04-03 13:23 -------
Subject: Re:  [4.3/4.4/4.5 Regression] tree-ssa-sink
 breaks stack layout

On Fri, 3 Apr 2009, sandra at codesourcery dot com wrote:

> ------- Comment #9 from sandra at codesourcery dot com  2009-04-03 12:54 -------
> After the merge of the alias_improvements branch to trunk, the test case no
> longer compiles incorrectly at -O1.  Is this coincidence, or a real fix that
> addresses the underlying problem?

I believe this is a coincidence.  Can you investigate what the difference 
is?

Richard.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[dougkwan at google dot com]

------- Comment #11 from dougkwan at google dot com  2009-05-09 01:21 -------
We saw this also in gcc-4.3.1 on target arm-none-eabi.


-- 

dougkwan at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dougkwan at google dot com


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[dougkwan at google dot com]

------- Comment #12 from dougkwan at google dot com  2009-05-10 00:56 -------
Created an attachment (id=17840)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17840&action=view)
C test-case for the same problem on x86_64 and i386.

The original C++ test-case does not crash on x86_64 and i386.  I compared the
generated code and found that ARM EABI requires constructors to return values. 
That is not common and certainly is not the case on x86_64 and i386.  So gcc
generates very different code on both targert very early on.  The C test-case
was created based on the lowered C++ code in the middle-end.  It crashes with
just -O2 on x86_64 with both 4.3.1 and 4.4.0; it crashes on i386 similarly with
4.3.1.  I did not test 4.4.0 on i386.

Unfortunately this does not crash on ARM.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[matz at gcc dot gnu dot org]

------- Comment #13 from matz at gcc dot gnu dot org  2009-05-10 02:09 -------
Created an attachment (id=17843)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17843&action=view)
type-correct version

This is a type-corrected version of the same C testcase.  Two structs are
different types even if they contain the same members, so the casts and
accesses as 'struct a' where the object really was 'struct b' are not valid.
That can be solved by modeling the same as in C++, via proper subobjects of
base-type.

This testcase still exhibits the abort() with -O2 with 4.3.2 on i386 and
x86_64.  It doesn't fail with current trunk, but most probably for the same
coincidence since a-i merge.  I haven't checked 4.4.x.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2009-05-10 10:00 -------
Another possible solution that was mentioned is to delay stack slot allocation
until after scheduling (or possibly later code motion optimizations).  Before
that stack slots could be represented by their own pseudos (pointers to the
base of the stack slots) and conflict analysis could be done on RTL based on
life ranges of the memory pointed to by them.  A complication is how to recover
scope based lifetime rules if the stack slots escape to function calls
(but I suggested to do these merging opportunities early on the tree level,
during gimple lowering).


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[steven at gcc dot gnu dot org]

------- Comment #15 from steven at gcc dot gnu dot org  2009-05-10 13:51 -------
The late stack slot allocation idea will just cause other problems, like
missing CSE of addresses.  GCC should just get the conflicts right somehow...


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenther at suse dot de]

------- Comment #16 from rguenther at suse dot de  2009-05-10 14:14 -------
Subject: Re:  [4.3/4.4/4.5 Regression] tree-ssa-sink
 breaks stack layout

On Sun, 10 May 2009, steven at gcc dot gnu dot org wrote:

> ------- Comment #15 from steven at gcc dot gnu dot org  2009-05-10 13:51 -------
> The late stack slot allocation idea will just cause other problems, like
> missing CSE of addresses.  GCC should just get the conflicts right somehow...

"somehow..." ;)

I don't see how without making the coalescing decisions part of the IL
on RTL (and of course see if coalescing is even possible before doing it).

What about dropping all MEM_EXPRs for accesses to coalesced variables?
With the new memory-model that should be enough, without it you'd also
need to make the use alias set zero.

Richard.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[steven at gcc dot gnu dot org]

------- Comment #17 from steven at gcc dot gnu dot org  2009-05-10 14:22 -------
How will dropping the MEM_EXPRs solve the wrong coalescing in cfgexpand?


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenther at suse dot de]

------- Comment #18 from rguenther at suse dot de  2009-05-10 14:32 -------
Subject: Re:  [4.3/4.4/4.5 Regression] tree-ssa-sink
 breaks stack layout

On Sun, 10 May 2009, steven at gcc dot gnu dot org wrote:

> ------- Comment #17 from steven at gcc dot gnu dot org  2009-05-10 14:22 -------
> How will dropping the MEM_EXPRs solve the wrong coalescing in cfgexpand?

Not.  That was just to avoid making coalescing decisions part of the IL
for RTL.

Richard.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2009-08-04 12:30 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[ramana at gcc dot gnu dot org]

------- Comment #20 from ramana at gcc dot gnu dot org  2009-09-18 07:19 -------
*** Bug 41354 has been marked as a duplicate of this bug. ***


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |erik at arbat dot com


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2009-12-16 20:53 -------
In a discussion we decided that introducing a __builtin_undefined () that
we can assign to variables at the point they die would be the proper way
to fix this.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2010-03-08 22:50 -------
This is the same as bug 39509. 

*** This bug has been marked as a duplicate of 39509 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[sandra at codesourcery dot com]

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

--- Comment #23 from Sandra Loosemore <sandra at codesourcery dot com> 2011-06-01 17:34:56 UTC ---
Draft patch that addresses this bug here:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02029.html