Here's an updated draft. I included most of your remarks and added some notes on append-flags/filter-flags. I'll probably submit it to Ulrich around the end of the week.
--- Draft BEGIN --- <section> <title>CFLAGS</title> <body> <p> 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 and CFLAGS tuning is not an exception. </p> <p> The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the 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. Example of this are : <ul> <li>nss_ldap stopped working with <c>-ffast-math</c> (reported to break many packages changing with the actual gcc version)</li> <li><c>-fvisibility-inlines-hidden</c> still breaks some code</li> <li>if you used gcc-4.0, <c>-ftree-loop-linear</c> now breaks in gcc-4.1(at least with mesa)</li> <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> <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> </ul> </p> <p> Users with unsupported CFLAGS (see the <uri link='http://gentoo-wiki.com/CFLAGS_matrix'>CFLAGS matrix</uri> for example) might want to return to safe CFLAGS (see <uri link='http://gentoo-wiki.com/Safe_Cflags'>Safe CFLAGS</uri>) 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. </p> <p> Notes: <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> </p> </body> </section> --- Draft END --- Lionel -- gentoo-dev@gentoo.org mailing list
