From owner-freebsd-stable Mon Oct 21 14:10:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF1DE37B401 for ; Mon, 21 Oct 2002 14:10:08 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 295B643E75 for ; Mon, 21 Oct 2002 14:10:08 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id g9LLA64D010976; Mon, 21 Oct 2002 14:10:06 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g9LLA63c010975; Mon, 21 Oct 2002 14:10:06 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 21 Oct 2002 14:10:06 -0700 From: David Schultz To: Charles Swiger Cc: stable@FreeBSD.ORG Subject: Re: GCC options, was: Re: 4.7-RELEASE crash [file system] Message-ID: <20021021211006.GA10857@HAL9000.homeunix.com> Mail-Followup-To: Charles Swiger , stable@FreeBSD.ORG References: <20021019130404.A25131-100000@edge.foundation.invalid> <001901c27798$d033df70$0301a8c0@prime> <3DB2399F.3060900@zbzoom.net> <003a01c27849$6367d4d0$0301a8c0@prime> <20021021161902.GA396@HAL9000.homeunix.com> <006501c27929$67cf3cd0$0301a8c0@prime> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006501c27929$67cf3cd0$0301a8c0@prime> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Charles Swiger : > > GCC specifically does *not* generate code that is any more or less > > reliable when you use -g. The GCC folks are fairly picky about > > that rule. > > The GCC team wants the compiler to produce reliable code under all > circumstances, most likely. What the compiler actually does may not > correspond perfectly to that intention. Their official policy is that gcc is supposed to produce identical code with and without -g. For example, there's a loop unrolling optimization that can't be done with -g, and therefore it is not done at all. It's certainly possible that they screwed up somewhere, but I doubt it. > > As for optimization, I've never been bitten by any bugs in either -O0 > or -O, > > but in theory -O0 would save you from any bugs in the optimizer. > > -O0 means to disable the optimizer, agreed. However, the optimizer isn't a > single thing; it's an entire range of individual optimization techniques. > > Different -O levels (-O0, -O, -O2, etc...) enable different combinations. > Using -g may change some of the optimizations, such as disabling > "-fomit-frame-pointer", if they are incompatible with symbolic debugging. I don't think -O enables -fomit-frame-pointer period if the target architecture can't support debugging without a frame pointer. As I said above, I think they got the -g thing right. ;-) But I take your point that -O0 is sufficiently different from -O that the former could lead to bad interactions that don't crop up with -O. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message