Re: optimization/5040: g++-3.0.2: -O causes variables from different stack frames to overlap

[Gwenole Beauchesne <gbeauchesne@mandrakesoft.com>]

The following reply was made to PR optimization/5040; it has been noted by GNATS.

From: Gwenole Beauchesne <gbeauchesne@mandrakesoft.com>
To: rth@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
        <jeremy.barnes@idilia.com>, <rth@gcc.gnu.org>, <jakub@redhat.com>,
        <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: optimization/5040: g++-3.0.2: -O causes variables from different
 stack frames to overlap
Date: Fri, 12 Apr 2002 16:42:36 +0200 (CEST)

 On 4 Apr 2002 rth@gcc.gnu.org wrote:
 
 >     Can't reproduce with unpatched 3.0.3 or 3.1; as yet, the
 >     bug can only be shown vs Mandrake rpms.
 
 OK, on the Mandrake side I could isolate the problem to the following
 patch:
 
   - Patch604: Change heuristic for inlining of functions in C++:
     Rather than allowing one single function to exhaust the limit,
     allow only half way. Afterwards don't cut abruptly, but get more
     and more restrictive until a minimum size. This gives better
     runtime and compiletime results than the old heuristic.
     (Kurt Garloff, SuSE release 3.0.X-34)
 
 However, the problem is also reproductible with the unpatched FSF gcc
 3.0.5 20020404 (prerelease) as follows:
 
 Jeremy's second test case will crash if compiled as
 -O<X> -finline-limit=399, with X = { 1, 2 }
 
 But will succeed with -finline-limit >= 400.
 
 Jakub, hadn't you encountered a glibc miscompilation with gcc-3.1 when the
 -finline-limit was too low and the tree inliner used? Could it be related
 to this problem?
 
 >     Re-open or create a new PR when you get a chance to try
 >     your complete application vs gcc 3.1.
 
 Is the new data enough to re-open or create a new PR?
 
 Bye,
 Gwenole.