From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28629 invoked by alias); 3 Jun 2004 21:17:05 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 28620 invoked from network); 3 Jun 2004 21:17:03 -0000 Received: from unknown (HELO atom.nocdirect.com) (69.73.170.10) by sourceware.org with SMTP; 3 Jun 2004 21:17:03 -0000 Received: from [206.163.121.144] (helo=markab.pegasus.voria.net) by atom.nocdirect.com with esmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1BVza1-0007Uj-0L; Thu, 03 Jun 2004 16:16:53 -0500 Subject: Re: Weird optimization bug...? From: Adrian Bentley To: Eljay Love-Jensen Cc: gcc-help@gcc.gnu.org In-Reply-To: <6.0.3.0.2.20040603132957.02031898@iplan-mn.corp.adobe.com> References: <1086207843.11377.10.camel@localhost> <6.0.3.0.2.20040603062352.02150e10@iplan-mn.corp.adobe.com> <1086283457.18157.13.camel@localhost> <6.0.3.0.2.20040603132957.02031898@iplan-mn.corp.adobe.com> Content-Type: text/plain Message-Id: <1086297425.18157.38.camel@localhost> Mime-Version: 1.0 Date: Thu, 03 Jun 2004 21:17:00 -0000 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - atom.nocdirect.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - voria.com X-Source: X-Source-Args: X-Source-Dir: X-SW-Source: 2004-06/txt/msg00032.txt.bz2 So I looked at the assembly and didn't find anything super glaring. The compiled code was very different, so I'm not surprised the result is different. I haven't gotten any closer to figuring out what kind of mis-optimization it's doing (or if it's something else totally bizarre). Any other pointers for narrowing it down, or should I just hack it and wait for a new version of gcc to come out :). Thanks again, Adruab On Thu, 2004-06-03 at 11:36, Eljay Love-Jensen wrote: > Hi Adruab. > > >However, if that was the case, inserting a random function into the code > certain shouldn't fix the problem :P. > > Inserting a random function into the code can affect the optimizer, which > can mask the problem. > > I recommend taking a look at the assembly file to see what's different > between having and not having the extra function present, in the optimized > code. > > You can use the "-save-temps" to keep the assembly file around, and > "-fverbose-asm" for extra blather. > > HTH, > --Eljay > > >