Safe CFLAGS
Being able to tune CFLAGS is part of the user control and extreme configurability that are hallmarks of the Gentoo experience. Being in control brings both benefits and problems. CFLAGS tuning is not an exception.
Warning: Using anything beyond -O2 -fomit-frame-pointer -march/-mcpu/-mtune in CFLAGS or CXXFLAGS (and -mieee, -mabi etc. on selected archs that tell you to do this), and using anything at all in LDFLAGS or ASFLAGS, is usually not worth the trouble for most users. There's usually very little benefit, if any, high risks, and large amounts of time spent on frustrating tuning that could be enjoyed doing far more interesting things.
The recent upgrade to GCC 4.1 for stable x86 and amd64 users changed the CFLAGS landscape. Users that spent some time tuning their CFLAGS with GCC 3.4 might find that an upgrade to GCC 4.1 leaves them with an unstable system.
Examples of this are:
nss_ldap stopped working with -ffast-math (-ffast-math is often misused and must be considered a dangerous flag)
-fvisibility-inlines-hidden still breaks some code
-ftree-loop-linear now breaks in GCC 4.1 (at least with mesa)
-ftree-vectorize 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)
-fforce-addr and -fweb break regularly on x86 with video libraries or graphic processing apps which use hand-optimized assembly (-fweb may be safe on amd64 but like above no guarantees)
There are known-to-be-broken flags for all GCC versions that you want to check for too:
-fvisibility=hidden
-frename-registers (may be safe on amd64, at your own risks)
-ftracer
-D_FILE_OFFSET_BITS=64
-msse, -mmmx, and -m3dnow (no need for them on amd64, they are wrapped up by -march=k8/nocona/... and safely used there)
-W
-mfpmath=sse,387
-malign-double
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).
Final notes:
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.
Some options that are unsafe in the system-wide CFLAGS might be added automatically in some ebuilds if the developer deems them safe (by redefining CFLAGS or using append-flags from the flag-o-matic eclass). For example -ffast-math is added by the xmame/xmess ebuilds on most architectures even though you should not put it in your CFLAGS.
You might get an idea of the stability issues of a specific optimization option by running: find /usr/portage -name '*.ebuild' | xargs grep -- '-your-risky-optimization-option'. It takes quite some time, but might be enlightening: look for the 'filter-flags'.
http://www.gentoo.org/news/en/gwn/current.xml
世界永不缺乏偏执狂 :wink:
页:
[1]