From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 13 09:03:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57CB416A4CE; Fri, 13 Feb 2004 09:03:13 -0800 (PST) Received: from odot.okladot.state.ok.us (odot.okladot.state.ok.us [192.149.244.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4AC143D1F; Fri, 13 Feb 2004 09:03:12 -0800 (PST) (envelope-from root@techpc04.okladot.state.ok.us) Received: from notes9c.okladot.state.ok.us (notes9a.okladot.state.ok.us [10.36.36.31])LAA24548; Fri, 13 Feb 2004 11:03:12 -0600 Received: from techpc04.okladot.state.ok.us ([199.27.9.37]) by notes9c.okladot.state.ok.us (Lotus Domino Release 5.0.12) with ESMTP id 2004021311033757:11038 ; Fri, 13 Feb 2004 11:03:37 -0600 Received: by techpc04.okladot.state.ok.us (Postfix, from userid 0) id DC19E5C3B; Fri, 13 Feb 2004 11:03:47 -0600 (CST) To: "Kris Kennaway" From: "Paul Seniura" In-Reply-To: <20040213040929.GA58196@xor.obsecurity.org> References: <20040213001703.616C75C3B@techpc04.okladot.state.ok.us><20040213011324.GA55948@xor.obsecurity.org><20040213035608.3AA11A38EA@scifi.homeip.net><20040213040929.GA58196@xor.obsecurity.org> Message-Id: <20040213170347.DC19E5C3B@techpc04.okladot.state.ok.us> Date: Fri, 13 Feb 2004 11:03:47 -0600 (CST) X-MIMETrack: Itemize by SMTP Server on Notes9c/ODOT(Release 5.0.12 |February 13, 2003) at 02/13/2004 11:03:37 AM,2003) at 02/13/2004 11:03:38 AM, Serialize complete at 02/13/2004 11:03:38 AM cc: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org cc: Paul Seniura Subject: Re: need help on CFLAGS in /etc/make.conf please X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2004 17:03:13 -0000 > On Thu, Feb 12, 2004 at 09:56:08PM -0600, Paul Seniura wrote: > > > > Hi Kris, > > > > > On Thu, Feb 12, 2004 at 06:17:03PM -0600, Paul Seniura wrote: > > > > > > > > Hi y'all, > > > > > > > > I'm trying to find a way to do a CFLAGS+='-O' if and only if such a > > > > parm was not already provided before 'make' actually runs. > > > > > > > > I had this coded with the single = sign, i.e. without ?= or +=, but > > > > the process still acts as if += was coded anyway, thus tacking on > > > > my -O *after* the port's own CFLAGS. > > > > > > > > GCC33 docs say the _last_ -O# is the one that will be used. > > > > > > > > I've seen other discussion on using -O2 but the point seems to be the > > > > ports that set -O2 explicitly are likely to work correctly. > > > > On Thu 12 Feb 2004 17:13:25 -0800, Kris Kennaway replied: > > > That's not a good assumption; many ports simply add -O2 (or -O3, or > > > -O999) because the authors "want their code to run fast". The set of > > > ports for which the authors have run full regression suites for all > > > supported versions of gcc and all supported OS and architecture > > > combinations is probably the null set. > > > > Thank you for responding, but I'm *really* not wanting this to > > become another discussion on "how high my Oh-levels should be". ;) > > > > My question for this discussion is specifically how to prevent > > overriding a port's own setting for that parm, and to provide a > > default setting -O[1] when the port does not set it at all? > > > > (I'll save my l-o-n-g-e-r reply for later... believe me I have reasons ;) On Thu 12 Feb 2004 20:09:31 -0800, Kris Kennaway replied: > There's no general way. Some ports do ${CFLAGS} -O999, some do -O999 > ${CFLAGS}. While I haven't seen anything near -O999 yet (and I was a noobee in the 1980s with Microware OS-9[tm] on the CoCo3 [Tandy / Radio Shack] and Atari-ST [Cumana UK]), it is one reason to override it -- somehow -- in a consistently reliable way. > The ports collection policy is that any port that > specifies its own optimization flags by default and uses them in > preference to ${CFLAGS} is a bug and must be fixed. Well now you've made me go do research and type the l-o-n-g response I didn't want to do. ;) Let's first deal with the notion that GCC has optimization bugs per se -- in & of itself -- irregardless of the quality of the source code and whether that code follows ISO standards. Here are some quotes from the readily-available on-line books: Chapter 2 of "FreeBSD Developers' Handbook": | 2.4 Compiling with cc | |[...] | | -O | Create an optimized version of the executable. The compiler | performs various clever tricks to try and produce an executable | that runs faster than normal. You can add a number after the -O | to specify a higher level of optimization, but this often exposes | bugs in the compiler's optimizer. For instance, the version of cc | that comes with the 2.1.0 release of FreeBSD is known to produce | bad code with the -O2 option in some circumstances. | | Optimization is usually only turned on when compiling a release | version. |[...] HUH?!? "the version of cc that comes with 2.1.0" has those -O bugs???? Good grief, we're running 5.x (-Current, actually)! I can't find any mention of any such bugs with GCC 3.x on i386. Reading http://gcc.gnu.org/bugs.html for further info on optimization bugs will lead one to believe higher likelyhood of incorrectly-written source code over compiler bugs, yet GCC 3.x provides ways to steer around such non-standard coding practices and still optimize it. Chapter 7 of "FreeBSD Architecture Handbook" (on-line version): | 7.6 Tuning the FreeBSD VM system | |[...] | By default, FreeBSD kernels are not optimized. You can set | debugging and optimization flags with the makeoptions directive in | the kernel configuration. Note that you should not use -g unless | you can accommodate the large (typically 7 MB+) kernels that result. |makeoptions DEBUG="-g" |makeoptions COPTFLAGS="-O -pipe" |[...] Precisely what I'm doing. For fun, I build another version of my custom kernel with -O2 to see how much of a difference can be 'felt' on this Puny Pentium2. ;) Chapter 21 of "FreeBSD Handbook" (on-line version): | 21.4.16.5. How can I speed up making the world? | |[...] | * Also in /etc/make.conf, set CFLAGS to something like -O -pipe. | The optimization -O2 is much slower, and the optimization | difference between -O and -O2 is normally negligible. |[...] No mention of bugs there, either. In fact the book is actually recommending the use of -O. After much more contemplation on this, I can see the need for both circumstances: (1) overriding a port's -O as well as (2) allowing a port's -O to override mine. I'll be switching hats during the discussion below. The only real bug is that I as a system admin may not be able to override a port's inclusion of a -O parm because of where ${CFLAGS} is placed. "Placement" is the operative word here. And I can see a reason to open PRs and submit patches to 'move' its placement such that /etc/make.conf can effectively override it. If an app is ready for end-user use, I would definitely want to optimize it, as a system admin. I would need to trust the author(s) settings in this regard.- If I were the author and knew the app works with a higher -O level, then I would include the proper -O value in my configure scripts. If the app breaks after such optimization, then it is not ready for end-user use. I'd sooner put the weight of blame on the author(s) of the app -- not GCC in & of itself, not yet. If the app breaks on a particular platform, being the author I can modify configure scripts to work around it. If I am a system admin, I may or may not be able to override the port's -O due to the placement of ${CFLAGS}. This is a bug. MPlayer is a good example. When I download a pristine CVS copy and compile it on my Panther (MacOSX) box at home, it will set -O4 and turn on all kinds of features to milk Apple's G4 for everything it can do -- without modifying anything in that CVS package. But on this Pentium2 box, compiling mplayer only sets -O2 and turns on just a few of the other features. The author seems to know what compiler options will work for each platform. Both compiled versions do work. This is why I will trust the -O set by the config scripts themselves, but only up to a certain level (-O2 on P2, -O5 on G4). The bug is that I may or may not be able to override the port's -O with /etc/make.conf depending on the placement of ${CFLAGS}. Aside from this is the notion of letting certain other platforms 'beat' your chosen one merely because you aren't able to run optimized binaries or willing to fix it so. ;) > Kris -- thx, Paul Seniura (in OkC)