* [gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN, 3rd version
2006-10-03 23:08 [gentoo-dev] [RFC] CFLAGS paragraph for the GWN, 3rd version Lionel Bouton
@ 2006-10-04 6:18 ` Duncan
0 siblings, 0 replies; 2+ messages in thread
From: Duncan @ 2006-10-04 6:18 UTC (permalink / raw
To: gentoo-dev
Lionel Bouton <lionel-dev@bouton.name> posted
4522ED7B.8040205@bouton.name, excerpted below, on Wed, 04 Oct 2006
01:08:43 +0200:
> Here's the third version of the draft, wiki-free and with less sugar
> too. More warnings.
Thanks for your patience in drafting this. I believe it's well worth the
trouble and will likely be of help to many users. =8^)
> Being able to tune the CFLAGS is part of one of the core principles of
> Gentoo: let the user be in control. Being in control brings both
> benefits and problems. CFLAGS tuning is not an exception.
I read the feedback on the earlier versions and some may not agree with me
here (fine by me), but this now seems a bit awkwardly worded ("part of
one") and IMO actually waters it down a bit /too/ far. Perhaps rewording a
bit makes it less awkward? How does the following work for the first
sentence above. (Linking the official Gentoo about page /is/ acceptable,
one hopes.)
Being able to tune CFLAGS is part of the user control and extreme
configurability that are hallmarks of the <uri
link=http://www.gentoo.org/main/en/about.xml> Gentoo experience</uri>.
> <warn>
Good! Keep the warning just like it is, and where it is, right up front!
=8^)
> <li>nss_ldap stopped working with <c>-ffast-math</c> (reported to break
> many packages changing with the actual gcc version)</li>
I believe some of the discomfort you are seeing stems from wording like
this. -ffast-math in general CFLAGS has been repeatedly referenced as
/the/ archetypical example of riced out users gone totally ricer-mad
insane. In fact, there was discussion a couple months ago of replacing
all those calls to filter-flags -ffast-math with a (possibly
portage-universal) call to die -- emerge simply refusing to do /anything/
but spit out the warning, until that flag was removed.
The choice of wording on this flag then remains FAR too mild to satisfy
many. Something along the lines of "this flag may cause your computer to
incinerate like a Sony battery powered laptop!" I'm sure would be far more
to their liking. =8^P
A bit more seriously, a warning that at minimum, users choosing to use
this flag can expect many bugs they file to be closed INVALID or WONTFIX,
regardless of whether the bug is related or not, simply due to the number
of packages that this flag has been found to break and therefore the level
of reliability of the reporter found to be using it, might be appropriate.
Or simply, a DON'T USE THIS FLAG. YOU HAVE BEEN WARNED, if you prefer.
The latter may seem a bit extreme, but look at it from the viewpoint of a
developer who has repeatedly spent hours tracking down bugs, only to find
out they are related to something "stupid" like this, and it really
doesn't seem so extreme after all.
> <li>if you used gcc-4.0, <c>-ftree-loop-linear</c> now breaks in
> gcc-4.1 (at least with mesa)</li>
Please change the reference to gcc-4.0. That's needlessly confusing,
given that gcc-4.0 was never unmasked even to ~arch on Gentoo, especially
when you also mention 4.1 and are actually talking about it. Maybe simply
gcc-4, or gcc4?
> <li>again for gcc-4.0 users, <c>-ftree-vectorize</c> is known to be
> broken in gcc-4.1 (at least for x86 and ppc, amd64 users seem to be
> safe)</li>
I posted about this one before, but never saw my message on the list, so
it may not have made it. AFAIK, you are correct on x86/ppc, it breaks
there. However, I'd be rather more careful about saying "amd64 users seem
to be safe" with it. Unfortunately, many users are likely to parse that
as "amd64 users WILL be safe with it." Maybe something along the lines of...
amd64 users have reported fewer problems with this flag, but no guarantees.
> <li><c>-fforce-addr</c> and <c>-fweb</c> break regularly on x86 with
> video libraries or graphic processing apps which use hand-optimised ASM</li>
Conversely here, you don't mention other platforms at all, but I've been
using -fweb on amd64 for a very long time, likely since gcc-3.3, with few
if any issues. I'd personally call it relatively safe on amd64, but would
tend toward a bit more caution for GWN publication, with wording much like
that suggested for -ftree-vectorize. IOW...
amd64 users report fewer problems with this flag, but again, no guarantees.
> <p>There are known-to-be-broken flags for all GCC versions that you want
> to check for too:</p>
[snip]
> <li>-frename-registers</li>
Same here as with -fweb. I've been using it for quite awhile on amd64, no
known issues, so suggested similar or identical wording to the above.
> <li>-msse -mmmx -m3dnow</li>
You might mention that for amd64, these (except for -sse2 on the latest
amd versions) are wrapped up in the -march=k8/nocona/whatever, that should
be set for your hardware as appropriate. Thus, as long as that's set, no
need to worry about these at all on amd64.
> Users with unsupported CFLAGS might want to return to safe CFLAGS (see
> warning above) if recent updates caused them stability problems. On the
> other hand, more adventurous users might want to experiment with CFLAGS
> that didn't work properly with gcc-3.4.6... As always, the user is in
> control (and the gun pointed to their feet is in his/her hand). </p>
As with the intro warning, this looks perfect just as it is! =8^)
> <p>Final notes:</p>
> <ul>
> <li>The gcc man page contains warnings for some unsafe optimization
> options. You should read it carefully when you experiment with CFLAGS or
> upgrade GCC on a CFLAGS-customized Gentoo.</li> <li>Some options that
> are unsafe in the system-wide CFLAGS might be added automatically in
> some ebuilds if the developper deems them safe (by redefining CFLAGS or
> using append-flags of the flag-o-matic eclass). For example
> <c>-ffast-math</c> is added by the xmame/xmess ebuilds on most
> architectures even if you don't put it in your CFLAGS.</li> <li>You
> might get an idea of the stability issues of a specific optimization
> option by running: <c>find /usr/portage -name '*.ebuild'| xargs grep --
> '-<your-risky-optimization-option>'</c>. It takes quite some time, but
> might be enlightening: look for the 'filter-flags'.</li> </ul>
Likewise here, perfect, with one tiny exception. In keeping with the
above suggested far stronger wording on -ffast-math, change "even if you
don't put it in your CFLAGS" to "even tho you SHOULD NOT put it in your
CFLAGS".
JMHO as a(n amd64) user, FWIW, but HIH.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 2+ messages in thread