From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-17195-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4795 invoked by alias); 12 Apr 2002 14:46:06 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 4768 invoked by uid 71); 12 Apr 2002 14:46:04 -0000
Date: Fri, 12 Apr 2002 07:46:00 -0000
Message-ID: <20020412144604.4762.qmail@sources.redhat.com>
To: rth@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Gwenole Beauchesne <gbeauchesne@mandrakesoft.com>
Subject: Re: optimization/5040: g++-3.0.2: -O causes variables from different
 stack frames to overlap
Reply-To: Gwenole Beauchesne <gbeauchesne@mandrakesoft.com>
X-SW-Source: 2002-04/txt/msg00658.txt.bz2
List-Id: <gcc-prs.sourceware.org>

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.