Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Mar 2004 12:16:25 -0600 (CST)
From:      "Paul Seniura" <pdseniura@techie.com>
To:        "Nikos Ntarmos" <ntarmos@ceid.upatras.gr>
Cc:        Paul Seniura <pdseniura@techie.com>
Subject:   re: GCC optimization bugs -- still there or a historic artifact?
Message-ID:  <20040315181625.7D59D5C29@techpc04.okladot.state.ok.us>
In-Reply-To: <20040313192357.GA10778@diogenis.ceid.upatras.gr>
References:  <20040315001052.GA20921@diogenis.ceid.upatras.gr> <20040313192357.GA10778@diogenis.ceid.upatras.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

I was the one starting that question. ;)
I'd like to mention what I've done and found so far.

Please remember I can only vouch for the Puny Pentium2, since
I have no other machine to use here on li'l-endian models. 
Also I can vouch for GCC-3.3x on my G4 at home, but it is a
totally *totally* different system altogether.

My earlier question got splintered into several points.

My main point was dealing with FreeBSD's ports system Makefiles
overriding the author's settings in the original app's Makefile. 
If the original app's Makefile had set a high -O level, I want
FreeBSD to compile it at that same level, stop lowering it,
because we are not getting the full benefit that the original
author has intended.

Another point I want to do:  If an app does not have any -O
set at all, I want to set it to a default level.  Or, to lower
it if it is too high (although I have not seen this case).

The simple way of setting any CFLAGS in /etc/make.conf is not
sufficient.  CFLAGS is something that you can put anything into
it in a 'free form' way.  The simple make.conf can override it
or "add to" it, but that's all.  I need to be able to scan it
to see if there was any -O at all, then be able to change it if
it's too high, or to add a default -O if none found to begin
with.  This needs to be done "very late" before gcc is invoked
for each module.

Exactly where the Makefile will add your own CFLAGS -- either
before or after its own -- is dependent on how other parts of
the Makefiles handle it.  So yours may override theirs, or
theirs take precidence over yours; nothing is predictable. 
My hack, tho, if ever it will work properly, would scan
CFLAGS late enough but before gcc is invoked, and thus ensure
predictable settings no matter what.

This comes full circle to my first point, that some FreeBSD
ports system Makefiles are altering the original settings.  If
I can get my hack working, their changes would come through
*before* I could 'see' the *original* settings.  So I wanted
the maintainers to stop altering these settings.

I did not want the discussion to delve into issues with gcc
doing bad things, and I showed that the GNU GCC website does
have documentation to help authors deal with known bugs here. 
If the app runs on i386 using gcc-3.3.3 at a higher -O level
under Linux, say, then it ought to work under FreeBSD/i386 as
well.  You can assume those high -O levels were tested.  So I
wanted the FreeBSD maintainers to stop altering these settings,
to use what the original author has tested.

I mentioned in that earlier discussion that I will test MPlayer
at -O3, which is the setting of the original author.  I can now
with certainly say -O3 made a WHOLE LOTTA DIFFERENCE on this
Puny Pentium2 PC: it is actually usable now! (at least)

I haven't found a way to do my hack yet, though.  For the
time being, I am sort-of 'forcing' -O2 and -march=pentium2 in
the kernel and world builds -- which does help speed them up on
this Puny Pentium2.  A higher -O3 seems to make some modules
get stuck during the gcc compile phase, so that's why I said
anything higher can't be trusted on the Pentium platform.

As for building ports, if I see an app wanting to build higher
than -O2, I will remove my settings and restart the portupgrade
to let it use those settings for a trial run.

For other ports, they usually have -O set, others have -O2, and
many have nothing.  I make a judgement: if the app is used very
often, or it makes libs that are used a lot, I will try forcing
-O2 even if the original makefile is lower.

I can say letting KDE use its own settings at -O2, and forcing
other pieces to use -O2, makes it run much better overall. 

I just wish the maintainers would stop changing these settings
coming from the original projects, so we system admins can have
control over how things are compiled.

N.B.
This is good for the Puny Pentium2 machine "they" let me use
here at work. ;)  I have no idea on other/higher versions of the
Pentium.  And as for PPC, I've compiled things as high as -O5,
which is its limit I believe. ;)  Since the G4 is an entirely
different animal, tho, you cannot compare it to other such
vastly different platforms.


  --  thx, Paul Seniura.




>--- Original message ---<

Hi all.

There was a thread on the CFLAGS knob in make.conf in early Feb.'04
(the exact subject was "need help on CFLAGS in /etc/make.conf
please"), where some posters raised the issue of gcc optimization bugs
that supposedly manifest in optimization levels above -O2. The last
post on this subject was on Feb. 13th, though, and nothing has come up
ever since. AFAIK 5.2.1+ and -CURRENT have moved to gcc-3.3.3. Are
these issues still there?

I've been making my way around FreeBSD's and GCC's gnat and couldn't
find anything relevant. Ummm... Actually almost all relevant entries
in our gnat end with something like "bug the gcc guys for we're too
overwhelmed to look into gcc issues". The funny thing is there is no
entry in the gcc's gnat about optimization bugs in 3.3.3. As some very
specific person noted, "-O gets about an order of magnitude less
testing than -O2" by the gcc community.

This whole thing came up in the port-alpha@netbsd list, in a thread
about Compaq's C compiler (aka ccc) for linux/alpha (lang/compaq-cc in
our ports tree) and its status in NetBSD. The manpage for make.conf
states that the issues with levels >1 are even worse on alpha. Well,
gcc-3.3.3 is as fast as (if not faster than) ccc for optimization
levels above -O2, and can be used for a much wider part of the C/C++
source available out there. So the question is: are these gcc issues
still there or just a historic artifact left lurking around manpages
"just to be sure"?

\n\n

-- 
 Nikos "Noth" Ntarmos    | < ntarmos at ceid dot upatras dot gr >
 NetCINS Lab. @ C.E.I.D. | [ http://{noth,p2p}.ceid.upatras.gr/ ]
 U. of Patras - Greece   | ( 38.2594N, 21.7428E ) ( 1024D / CF95160A )



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040315181625.7D59D5C29>