need help on CFLAGS in /etc/make.conf please

Fri Feb 13 09:03:13 PST 2004

> 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):

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):

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)