Date: Fri, 13 Feb 2004 11:03:47 -0600 (CST) From: "Paul Seniura" <pdseniura@techie.com> To: "Kris Kennaway" <kris@obsecurity.org> Cc: Paul Seniura <pdseniura@techie.com> Subject: Re: need help on CFLAGS in /etc/make.conf please Message-ID: <20040213170347.DC19E5C3B@techpc04.okladot.state.ok.us> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040213170347.DC19E5C3B>