From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9474 invoked by alias); 3 Apr 2002 16:26:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 9445 invoked by uid 71); 3 Apr 2002 16:26:01 -0000 Date: Wed, 03 Apr 2002 08:26:00 -0000 Message-ID: <20020403162601.9444.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Jeremy Barnes Subject: Re: optimization/5040: g++-3.0.2: -O causes variables from different stack frames to overlap Reply-To: Jeremy Barnes X-SW-Source: 2002-04/txt/msg00230.txt.bz2 List-Id: The following reply was made to PR optimization/5040; it has been noted by GNATS. From: Jeremy Barnes To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jeremy.barnes@idilia.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: optimization/5040: g++-3.0.2: -O causes variables from different stack frames to overlap Date: Wed, 3 Apr 2002 11:22:59 -0500 We no longer have 3.0.2, but are using 3.0.3. The example I attached to the bug report works fine under 3.0.3. The problem still shows up in our application, however, but only when using -O, not on -O2, -O3 or -O6 any more. In general, something seems to be fixed in 3.0.3 vs 3.0.2, as it is much harder to reproduce, however it is still there somewhere. I don't have the time currently to bootstrap a CVS version of 3.1. I do have some code (the relevent parts of our app distilled into a single source file) that still reproduces the problem under 3.0.3. I can send it to an individual developer, but would prefer not to send it to a public mailing list. Respond if you are interested. My suspicion is that it won't show up in 3.1 using this source file, as the example is extremely brittle. If this is the case, then the only way to be sure it is fixed and not hiding, would be to diagnose it back on the 3.0.2 branch, figure out where the problem was, and then look to see if it was fixed in 3.1. Sounds arduous...