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 readers.
--- Draft BEGIN --- <section> <title>CFLAGS</title> <body> <p> 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>. Being in control brings both benefits and problems. CFLAGS tuning is not an exception. </p> <warn> 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. </warn> <p> 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> <p>Example of this are :</p> <ul> <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 mesa)</li> <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 guarantees)</li> <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> </ul> <p>There are known-to-be-broken flags for all GCC versions that you want to check for too:</p> <ul> <li>-fvisibility=hidden</li> <li>-frename-registers (may be safe on amd64, at your own risks)</li> <li>-ftracer</li> <li>-D_FILE_OFFSET_BITS=64</li> <li>-msse -mmmx -m3dnow (no need for them on amd64, there are wrapped up by -march=k8/nocona/... and safely used there)</li> <li>-W</li> <li>-mfpmath=sse,387</li> <li>-malign-double</li> </ul> <p> 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> <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 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 '<c>filter-flags</c>'.</li> </ul> </body> </section> --- Draft END --- Lionel -- gentoo-dev@gentoo.org mailing list
