Safe Cflags
Contents |
[edit] Introduction
This article lists the CFLAGS settings considered "safe" for a given processor. These are the settings you should use if you are unsure which CFLAGS your processor needs.
Please do not include any flags that aren't 100% safe. Just because it works for you doesn't mean it will for everyone else.
We aren't interested in benchmark scores, personal anecdotes, rumors, things your really smart uncle once told you, random -m flags that made your box dispense root beer, or any other discussion or debate. It will be removed. Take it to the talk page or the appropriate forum. Thanks.
[edit] GCC Version and CPU
These CFLAGS are for gcc 3.x and 4.x. To check your version:
You can see which CPU you have with the following command:
Note: pni = SSE3
If you're running Intel, you can also use x86info to get more detailed info about your chip:
[edit] General Information on CFLAGS
This page is for those who don't want to experiment, and want a stable system, but still optimized for their CPU. But remember, by using these flags, binaries from your system might not work on another one with a different CPU. So if you compiled with optimizations for a Pentium 4 (-march=pentium4), you can't share a hard disk or packages with a friend who only has a Pentium MMX (-march=pentium-mmx). Though the other way around should work, see below.
This is the case if you are using the -march flags. If you use -mtune instead without any -march option, your binaries are backward compatible down to i386, but the scheduling is optimized for your chosen architecture. CPUs are also backward compatible so if you update your system with a new CPU you can still use your old packages. There is one exception though: if your old CPU supports a feature that your new CPU doesn't. So if you have an Athlon (-march=athlon) and upgrade to a Pentium 4, your old packages might not work. You can mix -march and -mtune if you, for example, would like to create binaries that would run on any i686 but are optimized for a Pentium 4. This would be accomplished by using -march=i686 and -mtune=pentium4.
Note that -O2 is regarded as safer than "-O3". "-O3" can even produce slower code. On computers with limited cache and/or memory, "-Os" may provide better performance in some cases through smaller binaries, although it is slower when using the OpenSSL library with small keys (DSA keys with less than 2048 bits on VIA C3-2, 1200 MHz and 64 kb on-die cache).
For comparison of "-O2" and "-Os", see for example [1] and [2].
GCC has a number of flags for CPU features like MMX and SSE; -mmx -msse etc. They are implied if you use a correct -march option so you usually don´t need them, with some exceptions. They should not be confused with the similar USE flags for CPU features. The flag -mfpmath=sse however is not enabled by -march but it usually makes binaries slower due to limitations in the glibc headers. So it's better to not use this flag, even if you have an SSE capable CPU. Also -mfpmath=sse,387 is experimental and unstable.
The flag -fomit-frame-pointer is enabled at -O1, -O2, -O3 and -Os on arches where it doesn't interfere with debugging, such as AMD64, but not x86. So if you're on x86 you should add it to your CFLAGS. Also don't use -momit-leaf-frame-pointer together with -fomit-frame-pointer. It's pointless as -fomit-frame-pointer already omits all frame pointers. In fact if you use both, -momit-leaf-frame-pointer overrides -fomit-frame-pointer creating less optimized code.
Note that the -O3 and, specially, the -fomit-frame-pointer flag can hamper debugging (especially generating stack traces). This is important for developers and people who want to report certain kinds of bugs (such as bugs which result in crashes). See http://bugs.gentoo.org/show_bug.cgi?id=68282 for a discussion.
Also note that the benefits of O3 can be obtained without the potential drawbacks of larger object code by appending -fno-inline-functions -fno-ipa-cp-clone -fno-unswitch-loops to -O3.
[edit] -march=native
GCC 4.2 introduces a new -march option, -march=native, which automatically detects the features your CPU supports and sets the options appropriately. If you have an Intel or AMD CPU and are using >=sys-devel/gcc-4.2.3, using -march=native is recommended. Do not use -march=native if you use distcc on nodes with different architectures as this may produce unusable code.
Unfortunately the two commands above can give misleading info about flags like -mmmx and -mssse3, so to view what gcc really compiles with please use the next command:
See Hardware CFLAGS for more information.
[edit] Processor Specific CFLAGS
On the following pages you can find the CFLAGS specific to your processor.
