From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4934 invoked by alias); 30 Apr 2004 09:47:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4923 invoked from network); 30 Apr 2004 09:47:48 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sources.redhat.com with SMTP; 30 Apr 2004 09:47:48 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 10:46:14 +0100 From: "Dave Korn" To: "'gcc_mailing_list'" Subject: RE: optimization issue about -O2 and -Os Date: Fri, 30 Apr 2004 16:06:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <1083297951.1082.9.camel@leaf.tuliptree.org> Message-ID: X-OriginalArrivalTime: 30 Apr 2004 09:46:14.0921 (UTC) FILETIME=[FA66FF90:01C42E97] X-SW-Source: 2004-04/txt/msg01442.txt.bz2 > -----Original Message----- > From: gcc-owner On Behalf Of Jim Wilson > Sent: 30 April 2004 05:06 > On Thu, 2004-04-29 at 19:34, Ebony Zhu wrote: > > Have you ever been troubled in the same problem? Are you > sure it's a gcc > > bug, and not a mistake I probably made when building the cross tool? > > (e.g. missed some important options when building gcc). > > If something compiled with -O2 works and something compiled with -Os > does not work, then the logical conclusion is that the -Os option is > buggy. > > However, it is possible that something went wrong with your build, if > you are trying to do something complicated. Since you didn't say > anything about how you built the toolchain, or what you built, I can't > comment on this. I was just assuming that you had one toolchain, and > the only thing that changed was the -O2/-Os option when using it. > > I deal with gcc bugs everyday, but I don't have any specific knowledge > about -Os PPC gcc-3.3.2 bugs. > > You might try debugging the problem a bit to see what is > wrong. Run the > programs under gdb and see where they fail. Put a breakpoint > in main to > see if maybe they fail before main is reached. Etc. Use -fverbose-asm in conjunction with --save-temps to get a list of the optimisations in effect at the top of each assembler code file. Try it with -Os and -O2, and note the differences between them. You may be able to narrow it down to a specific -f flag by starting with -O2 and introducing the changes between that and -Os one at a time. cheers, DaveK -- Can't think of a witty .sigline today....