Here's a draft of a paragraph discussing CFLAGS-related problems. This
is the result of a discussion I started on gentoo-dev. Thanks to all
devs who gave feedback this should bring some food for thought to GWN

--- Draft BEGIN ---

Being able to tune CFLAGS is part of the user control and extreme
configurability that are hallmarks of the <uri
link=> Gentoo experience</uri>.
Being in control brings both benefits and problems. CFLAGS tuning is not
an exception.

We would like to remind you that using anything beyond <c>-O2
-fomit-frame-pointer -march/-mcpu/-mtune</c> in CFLAGS or CXXFLAGS (and
<c>-mieee, -mabi</c> etc. on selected archs that tell you to do this),
and using anything at all in LDFLAGS or ASFLAGS, is usually not worth it
for most users. There's usually very little benefit, high risks and much
time spent on frustating tuning that could be enjoyed doing far more
interesting things.

The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the
CFLAGS landscape. Users that spent some time tuning their CFLAGS with
gcc-3.4.6 might find out that an upgrade to gcc-4.1.1 leaves them with
an unstable system.
<p>Example of this are :</p>
<li>nss_ldap stopped working with <c>-ffast-math</c> (<c>-ffast-math</c>
is often misused and must be considered a dangerous flag)</li>
<li><c>-fvisibility-inlines-hidden</c> still breaks some code</li>
<li><c>-ftree-loop-linear</c> now breaks in gcc-4.1 (at least with
<li><c>-ftree-vectorize</c> is known to be broken in gcc-4.1 (at least
for x86 and ppc, there are fewer problems reported by amd64 users but no
<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.
<c>-fweb</c> may be safe on amd64 but like above no guarantees</li>

<p>There are known-to-be-broken flags for all GCC versions that you want
to check for too:</p>
<li>-frename-registers (may be safe on amd64, at your own risks)</li>
<li>-msse -mmmx -m3dnow (no need for them on amd64, there are wrapped up
by -march=k8/nocona/... and safely used there)</li>

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>Final notes:</p>
<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 tho you SHOULD NOT 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

--- Draft END ---

-- mailing list

Reply via email to