Talk:Safe Cflags
From Gentoo Linux Wiki
[edit] Is /proc/cpuinfo output actually useful?
This article is extremely long as is anyway. Is the output of /proc/cpuinfo actually useful in this context? Who's going to look at it and why?
Virtually every kernel supports /proc/cpuinfo, it can fairly frequently change with minor CPU revisions and if really needed this information could be split to a separate page. In my view it shouldn't be included in this article.
--AllenJB 22:59, 3 June 2008 (UTC)
[edit] DO NOT use -Os instead of -O2 on this page
We don't care about cache locality or performance here. This page is for safe CFLAGS. We have several examples of -Os breaking packages on certain archs with certain GCC versions in bugzilla. -- dirtyepic 01:03, 22 April 2007 (UTC)
[edit] Merge P4 Prescott and PD/CeleronD sections?
The sections about the Pentium 4 Prescott, Pentium D 8xx/9xx, and Celeron D all have the exact same content and the exact same CFLAGS, save for the model numbers. I propose that they be merged into one. Something along the lines of "Pentium 4 (Prescott), Pentium D, and Celeron D", perhaps? SignOfZeta 02:08, 15 July 2007 (UTC)
- Probably would not be a good thing. Depending on what changes the Cflags for these would change. And even if they are the same cflags they are different types of processors.
[edit] -fomit-frame-pointer Everyhere
There is no need of -fomit-frame-pointer CFLAGS that have: -O, -O2, -O3, -Os. Just take a look @ http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Optimize-Options.html where:
"-fomit-frame-pointer Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines. On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro FRAME_POINTER_REQUIRED controls whether a target machine supports this flag. See Register Usage." [...]
Enabled at levels -O, -O2, -O3, -Os.
- This is not true. If you read all of that page referring to the O levels, it says that it is only included if it doesn't affect debugging. On all x86 architectures, -fomit-frame-pointer does, in fact, affect debugging, so it is not included in the -O optimizations.
- Note that -fomit-frame-pointer does not significantly affect debugging information in GCC versions later than 4.0 anymore. Along with the splitdebug FEATURE, we can get decent backtraces on optimized code. -- dirtyepic 01:06, 22 April 2007 (UTC)
[edit] PPC G3 CFlags
I have problems with the recommended Cflags for the G3 on my beige G3. When I compile something I get often a compiler error. Sometimes it works the second, third... time. I don't know if it's -fsigned-char or -mpowerpc-gfxopt. I'm now using CFLAGS="-mcpu=750 -O3 -pipe" again - no problems.
[edit] -mfpmath=sse on P4?
Is it believed safe to run -mfpmath=sse on the P4? How about -mfpmath=sse,387? Is that still "experimental"?
- It's usually safe to set sse fpmath but it creates slow code. Using both sse and 387 is unstable.
- This isn't the case on netburst CPUs, the SSE regiesters are at least twice as fast as the FPU on this processor architecture for FP math. Of course the opposite is true on Pre-Pentium 3 and AMD CPUs.
- Sure but until gcc/glibc is fixed to generate optimized SSE code without costly register moves -mfpmath=sse is slower.
- It's true that SSE was improved for the Pentium 4. However, according to the GCC 4.3 documentation that has been posted, on a Pentium 4 (non-Prescott), -mfpmath=387 *should* create faster code than -mfpmath=sse:
{4, 5, 4}, /* cost of loading integer registers... */
{2, 3, 2}, /* cost of storing integer registers */
{2, 2, 6}, /* cost of loading fp registers in SFmode, DFmode and XFmode */
{4, 4, 6}, /* cost of storing fp registers in SFmode, DFmode and XFmode */
{2, 2}, /* cost of loading MMX registers in SImode and DImode */
{2, 2}, /* cost of storing MMX registers in SImode and DImode */
{12, 12, 12}, /* cost of loading SSE register in SImode, DImode and TImode */
{2, 2, 8}, /* cost of storing SSE registers in SImode, DImode and TImode */
- This cost-analysis shows that loading an SSE register can cost up to six times more than loading the same data into a 387 floating-point register. Unless you have code that specifically requires 128-bit precision, or has been hand-coded to use SSE or SSE2 instructions, -mfpmath=387 would theoretically produce faster code.
- Intel claims to have significantly sped up SSE in the Core series of CPU's. This correlates with the GCC 4.3 code for -march=core2, where SSE registers are two to three times less expensive. (Also, because all Intel Macs have a Core processor, Apple's GCC 4.0.1 defaults to -mfpmath=sse.)
- SignOfZeta 03:07, 15 July 2007 (UTC)
- No it doesn't. Apple's gcc uses the same as FSF's, ie. 387.
[edit] AMD Sempron 32 bit
Is -march flag for 32 bit Sempron really athlon64 as stated in Wiki? (CFLAGS="-march=athlon64 -O2 -pipe -fomit-frame-pointer") I expected something 32 bit".
Jiri
I compiled for sempron with -march=athlon64 to check, and i got lots of Illegal Instruction errors, which dissapeared immediately when i recompiled for -march=athlon, so I'm guessing this is wrong - can someone verify this for me?
Greenpenguin
-march=k8 or athlon64 is correct for a K8 core Sempron. Not all are K8 cores. If you lack SSE2, you have a K7 (athlon-xp).
-march does not set or care about 32- or 64-bit.
Monkeh
[edit] AMD Athlon 64
vendor_id : AuthenticAMD
cpu family : 15
model : 15
model name : AMD Athlon(tm) 64 Processor
stepping : 0
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer"
gcc 3.2.x, two months in production environment without any sign of instability.
- From what I know, -fomit-frame-pointer makes no sense on AMD64 !
- Is there any particular reason for leaving out -pipe in the AMD64 CFLAGS? Or was it just an oversight?
- No? In that case I'm going to add them in.
- Oops, someone already did...
- No? In that case I'm going to add them in.
Just to let you know...-O3 isn't a terribly safe optimisation. It won't crash anything, but it can and will do the opposite of what you want it to do: more often than not, -O3 will actually slow your system down. Its aggressive optimisations will bloat the binary, meaning that your machine will have to load a larger binary into RAM when you run an app compiled with -O3, and that will take more time than a binary produced without -O3.
Personally, I recommend either -O2 or -Os as the safe -O flag, as, in my opinion, they give the right balance between optimising the code and not bloating the binary.
- i agree. O3 actually can break things, increases compile time, and makes huge binaries. use -O2 for programs you run all the time, and -Os for programs you are constantly starting and closing.
- The CFLAG -Os currently borks things and isn't recommended: http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#cflagssee And yes, I tried it anyway. It broke stuff. :(
[edit] Missing CPU ?
Hi I was searching for proper flags for my CPU
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Intel(R) Celeron(R) M processor 1400MHz
Waht is that? Pentium-M / Centrino (Intel) or Celeron (Willamette) (Intel) or some new category.
- cpu family and model tend to say it's pentium-m like
Me, too:
cpu_family : 15
model : 2
model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.20GHz
I don't think that -march=pentium-m will work, cuz I think it's only for Centrinos. But I also experiance bad performance in KDE with -march=pentium4. Flags that worked well until now were -march=pentium3 -mcpu=pentium4. I used them as long as there bugs with SSL and pentium4. Please help me find the correct ones. Thanks in advance.
- "Celeron M" is a Pentium M with less L2 cache and no SpeedStep technology, so -march=pentium-m should be the best choice.
same model name, different model
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.30GHz
stepping : 8
I have no idea about a correct CFLAGS setting.
- cpu family and model tend to say it's pentium-m like
Me also:
vendor_id : GenuineIntel
cpu_family : 6
model : 8
stepping : 6
model name : Pentium III (Coppermine)
Me also:
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Pentium(R) 4 CPU 2.00GHz
Me also:
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
stepping : 6
* -march=nocona should be used with Core 2 Duo at least in 64-bit.
Is this good for the following as well?
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz
stepping : 6
--Hank2000 21:35, 23 May 2007 (UTC)
Hi, Does anybody know the correct cflags for the AMD ATHLON 600 (Model 1) aka ARGON
cpu family: 6 model: 1 model-name: AMD-k7 vendor_id_ authenticAMD stepping: 2 cpu: 600 Mhz
[edit] cpuinfo for various models
Dual Opteron 244
first one, dual Opteron 244. the family/model/stepping doesnt match anything on the list. this is not a dual core or anything like that, the box has two independent cpus. ive been using the following flags with few issues.
CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j3"
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 244
stepping : 10
cpu MHz : 1794.856
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 3598.43
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 244
stepping : 10
cpu MHz : 1794.856
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 3589.76
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
AMD Opteron 275 Dual Core
processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 33 model name : Dual Core AMD Opteron(tm) Processor 275 stepping : 2 cpu MHz : 2191.822 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 4382.68 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
Pentium 1.13A
this is a P3 Tulatin 1.13A, a precursor to the early P4s. socket 370 with a bit of a twist. the P3 cflags seem to work fine with this cpu.
UPDATE (2007-01-16): i just ran into the exact model of cpu here on a dual core dell Poweredge 1650. ~neX
CFLAGS="-O3 -march=pentium3 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j1"
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Pentium(R) III CPU 1133MHz
stepping : 1
cpu MHz : 1138.654
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 2281.55
[edit] Suggested CFLAGS not safe for my Intel(R) Celeron(R) processor
After many hard days of work on installing, emerging, remerging, and configuring all possible config files!, I found out that all my problems were solved by changing the suggested Cflags to a more conservative one.
Suggested Cflags: CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer"
First I tried: CFLAGS="-march=pentium4 -O3 -pipe" This option solved some minor problems for me.
Then I tried: CFLAGS="-mcpu=i686 -O3 -pipe"
The second one fixed all the problems (i.e. failed to emerge -update world, failed to emerge xorg-x11, etc.)
If the suggested flag worked for other Intel(R) Celeron(R) processors, then I guess the reason why it didn't work for me could be a machine (hardware) specific problem. Btw, I'm using Acer Aspire 1200.
---
Are you sure that you have Celeron II?
--- got the same problem on a celeron 1800mhz. cflags=i686 worked for me.
[edit] Celeron != Pentium 4
The Pentium 4 reference identifies them as (cpu family: 15) and (model: 0 or 2). Here comes my cpuinfo:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.40Ghz
stepping : 9
cpu MHz : 2395.013
cache size : 128 KB
physical id : 0
siblings : 1
...
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ssht tm pbe cid
xtpr
bogomips : 4734.97
[edit] AMD64 in mode 32 bits
And what flags are for " Opteron/Athlon64 (AMD)" in mode 32 bits ?
- Looking at the 4.0.2 source, it looks like the flags -march=athlon-xp -msse2 gives you all the optimizations (except for 64 bit ones) of -march=k8. Another way (I am less sure of this one) is to do CFLAGS="-march=k8 -m32 -O2 -pipe". A few things to notice though:
- I have no idea why -fomit-frame-pointer works well for Athlon-XP's, but not for K8's. I would leave it out, just to be safe.
- I know that you need to change CHOST to i686-pc-linux-gnu. What I don't know is if you are able to get away with this change only (i.e., it might work with CHOST="i686-pc-linux-gnu" and CFLAGS="-march=k8 -O2 -pipe").
- This is for gcc version 4.0.2. Things might change in future releases. Right now, the framework is there for different optimizations, but it just so happens that all the optimizations (except 64-bit and sse2) for the K8 are also used for Athlon-XP (and no more).
- In the case that the above happens, you'd be better off using CFLAGS="-march=k8 -m32 -O2 -pipe" rather than CFLAGS="-march=athlon-xp -msse2 -O2 -pipe".
- You should still add -msse3 if necessary.
- Because of lack of hardware, I haven't actually tried this out.
Well, tell me what works for you.--129.22.126.171 21:39, 8 January 2006 (GMT)
[edit] AMD64
About AMD64 sugestes march ... man gcc says: k8, opteron, athlon64, athlon-fx AMD K8 core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit instruction set extensions.)
And this case it looks better to use athlon64 or athlon-fx than k8.
- Actually the cpu-types k8, opteron, athlon64, and athlon-fx all give the exact same optimizations. On the other hand, the cpu-type x86-64 has neither 3dNOW! nor enhanced 3dNOW! --129.22.126.171 22:06, 8 January 2006 (GMT)
-
In the handbook there is a comment to use k8 when you have an Athlon 64. Here I learned that there is also a flag athlon64. Can I conclude from the comment above that k8 has EXACTLY the same effect as athlon64? If not, how do I trigger emerge to recompile all packages against this CPU? Either way, I think it would be good to update the handbook, and just name the tag athlon64 instead of k8.
- I wrote the comment above, and will again assert that the mentioned cpu types are identical. You can find the details in the gcc source tree (hint look for processor_alias_table). I would further state that k8 is shorter to type and is more inclusive (if you're have an opteron, it might seem strange/confusing to use athlon64) than athlon64, and as such, the comment should be reverted. As for recompiling everything, you could always do an emerge -e world :).--129.22.124.228 03:43, 7 November 2006 (UTC)
- What's with Mobile AMD64? There is nothing mentioned... --84.180.1.97 12:37, 7 October 2007 (UTC)
- Shouldn't the -msse3 CFLAG be mentioned for AMD64 cpus with pni listed under flags at /proc/cpuinfo ? GCC man says it is not included in -march=athlon64/k8 and pni indicates whether the cpu can use SSE3 or not and as far as I know it's stable since GCC 4.0. kthxbye :)
The /proc/cpuinfo snippets are good, can we perhaps get more of them as there are quite a few revisions of the Athlon 64s and some have different features, such as SSE3? I posted mine for a Socket 939 X2, and I know that the AM2 X2s are stepping F, which relates to "2" in the /proc/cpuinfo shots. If anybody has an A64, post the cpuinfo, particularly to tell the difference between the SSE2 ones and SSE3 ones, since cpuinfo doesn't tell the core name like it did for some older Intel chips like the PII and PIII.
Ok, here's another "cpuinfo snippet". I think its a 'Venice' Model 2F
processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3800+ stepping : 2 cpu MHz : 2400.122 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow pni bogomips : 4734.97
--212.202.50.92 17:57, 2 October 2006 (UTC)
[edit] K6-2+, K6-II+ and K6-III+
There are 2 differently labled releases of K6-2+, one series labled as "2+", ther other as "II+". I have two II+-es and one 2+ and I see no difference.
These and the III+-series are extended versions of the III-series without the "+", so they safely can be fed with -march=k6-3 code.
- Actually the cpu-types k6-2 and k6-3 give the exact same optimizations (at least in gcc version 4.0.2). --129.22.126.171 22:12, 8 January 2006 (GMT)
[edit] centrino/mobile settings
The page currently says "NB: Never use -march=pentium4 with this processor. While it supports SSE2, the actual core is basically an enhanced pentium3. The pentium-m was designed by a completely different team in Israel" yet according to http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/i386-and-x86_002d64-Options.html there is a pentium4m, pentium3m, and pentium-m for gcc 3.4. I wonder which one is safe?
- This is often a source of confusion. First off, pentium3m is an alias for pentium3 and pentium4m is an alias for pentium4. Second, there is a clear division from cpu family : 6 to cpu family : 15. If you have the former, it is imperative that you not use pentium4. With cpu family : 15, it is definitely a good idea to use pentium4 (this is the case for the newer desktop-based Pentium-M and also notebooks with the Pentium 4 Mobile processor). Now we look at the distinction between pentium3 and pentium-m. I would estimate at least 90% of all Pentium-M processor candidates (most notebooks, the ULV Celerons, etc) are best optimized by -march=pentium-m. The flag -march=pentium3 is for the earlier ones and for Pentium III Mobiles. The difference is SSE2. You can tell what sse support your cpu has by running grep 'sse' /proc/cpuinfo. If you see sse but you don't see sse2, you are in the minority that needs to use -march=pentium3. A pentium-m processor has the core of a PIII (cpu family : 6), but unlike the PIII, it has sse2 support. Also, -march=pentium3 can be safely used with the newer processors as well (NOTE: not with cpu family : 15). This is because the switch -march=pentium-m is effectively the same as -march=pentium3 -msse2. You don't have to take my word for this, you can find it all in the gcc sourcetree (look for processor_alias_table[] in i386.c). --24.93.206.219 06:55, 8 January 2006 (GMT)
[edit] -Os on i486 but -O2 on i386?
Wouldn't it be better to put -Os on i386? (Ok, we will hardly ever install Gentoo on a 486 or even 386, but since these are listed, let's write the best flags for them) CrazyTerabyte 19:47, 26 December 2005 (GMT) Is it that 386s won't have enough cache to make it worth bothering to try and minimize the size, since there's no way it will fit in cache, so you might as well optimise for speed? Wheras a 486 has just enough cache that code with -Os can use it much better than that without? And FWIW I'm compiling on a 486 right now. 131.111.8.99 17:55, 7 February 2006 (GMT)
Intrigued by your suggestion about why -O2 on 386. Some more data on this: if I remember correctly, 386 ran synchronously with the mboard, and there was an external cache between mboard and memory (size being up to the mboard designer). Also 386 is not pipelined, so each instruction takes several clock cycles, and the more arcane x86 CISCisms (string instructions, complex addressing) tended to save time as they meant more complex processing could be performed with fewer clock cycles wasted fetching and decoding. For that reason I'd guess that there is little difference between -O2 and -Os on 386. 210.54.25.72 08:22, 11 September 2006 (UTC)
[edit] -Os in pentium4
I have read that -Os can be a good cflag for pentium4, why is it not secure?
- That would be good for P4's due to the NetBurst. "Its main handicap was a shared uni-directional bus."(Wikipedia) I'm not sure -Os is considered stable though. If it is stable it really should be on the P4's.
[edit] -O3 better than -O2 (-finline-limit=n)
I agree with you, when saying "-fomitframe-pointer" explicit spec. is not need because is enabled in all -Ox levels as you read.
Anyway, I this part is very good, this makes you able to optimize with "-O3" without bloating your binay as somebody says, isn't it ?
-finline-limit=n
By default, gcc limits the size of functions that can be inlined. This flag allows the control of this limit for functions that are explicitly marked as inline (i.e., marked with the inline keyword or defined within the class definition in c++). n is the size of functions that can be inlined in number of pseudo instructions (not counting parameter handling). The default value of n is 600. Increasing this value can result in more inlined code at the cost of compilation time and memory consumption. Decreasing usually makes the compilation faster and less code will be inlined (which presumably means slower programs). This option is particularly useful for programs that use inlining heavily such as those based on recursive templates with C++.
Inlining is actually controlled by a number of parameters, which may be specified individually by using --param name=value. The -finline-limit=n option sets some of these parameters as follows:
max-inline-insns
is set to n.
max-inline-insns-single
is set to n/2.
max-inline-insns-auto
is set to n/2.
min-inline-insns
is set to 130 or n/4, whichever is smaller.
max-inline-insns-rtl
is set to n.
[edit] ATHLON XP Variant added to list
I had a cpuinfo response that didn't match any of the listed CPU's but was half way between the XP and MP listings. I posted on the forums [1] and got a response from another poster confirming that my CPU was definitely an XP. (He had a known XP with the same cpuinfo) I have added the relevant parts (bolded below) of my info to the article page as a variant.
This is more than likely an Athlon XP with a Barton core, as it is the only Athlon XP which has 512KB of L2 cache.
- 66.31.97.91 22:23, 6 February 2007 (UTC)
My cpuinfo is as follows, diff from article bolded:
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 2500+ stepping : 0 cpu MHz : 1830.030 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips : 3664.15
--Gooserider 20:11, 13 September 2006 (UTC) What is CFLAG for 4 Xeon processor? processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 1 model name : Intel(R) Xeon(TM) CPU 1.40GHz stepping : 1 cpu MHz : 1401.042 cache size : 256 KB physical id : 2 siblings : 2 core id : 2 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 2793.47
[edit] Pentium M/4 Variant
I'm not sure where to add this CPU and I'm not sure which flags is safe for it? Can anybody place this please?
i have the same processor, an this is listed under pentium 4, but ther the model doesnt fit, and under celeron, but it is no celeron
Cheers
processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz stepping : 7 cpu MHz : 1800.000 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid bogomips : 3591.59
i tried some combinations and found the p4 working very good... added this cpu to the list
[edit] AMD Duron 1.8 GHz
Here's an odd CPU. It appears to be a 1.8 GHz Duron; however, I can't find such a processor on this page. Can someone identify which CFLAGS to use for this? (I'm guessing -march=athlon-xp would do fine.)
vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Duron(tm) processor stepping : 1 cpu MHz : 1792.962 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips : 3588.24
[edit] Celeron (Covington/Mendocino), aka Celeron1 (Intel)
Using -O2 seems like it might not be the best choice for this processor. While Mendocino had 128KB of L2 cache, some of you may remember that there was an even earlier Celeron, named Covington. Covington, clocked at 266MHz and 300MHz, lacked an L2 cache entirely. Either way, it seems that -Os would be a more reasonable flag to pass to gcc.
[edit] Core 2 Duo / Merom
As I've noted on the page, intel recommend nocona on c2d for both 32 and 64 bit, and prescott for c1d. Since this isn't about ricing, why are people recommending a flag that intel themselves won't recommend? And why did someone point people to using gcc 4.3 when it's ridiculously unstable and only available in the 'toolchain' overlay via layman? --ElPenguin
there are a number of core libraries (ie libc) that are built differently in Gentoo according to the ABI determined by your profile. if you're using a 32bit profile such as default-linux/x86, using -march=nocona will break that ABI, generating 64bit objects that will not link with 32bit code. if you use a multilib profile such as default-linux/amd64, then nocona is correct for both 32 and 64bit.
- That is not true. Using -march=nocona on a 32bit system generates 32bit code. I have my whole system running in 32bit mode using nocona.
- Even gcc-4.2 uses -march=nocona if using -march=native on 32bit ``gcc -Q -v -march=native hello.c -o /dev/null 2>&1|grep 'options passed' => options passed: -v -march=nocona -mtune=generic -auxbase. Also my system has been using -march=nocona for ~year with 32bit without anything breaking. 82.141.85.246
[edit] AMD XP 3200+
This Proc is a socket A with a 400mhz fsb & 512 L2 The current wiki is not clear on what flags should be used. That said, I've run it in the past with amd-xp flags and was sucessfull, although it was somewhat unstable (most likely faulty hardware and not flag related)
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 3200+ stepping : 0 cpu MHz : 2205.004 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips : 4414.76
[edit] AMD/NSC Geode GX1 & cmov
The GX1 (SC1100) is apparently a 586-class proc, but does support cmov (an instruction used by -march=686 on up). Is there a way to enable use of cmov without the other i686 stuff?
63.249.22.109 06:36, 23 April 2007 (UTC) (robink at creosotehill dot kauffmanfamily dot org)
- Judging by http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/i386.c?view=markup it will be enabled with -march/-mtune=geode in gcc 4.3 (assuming geode is right for that processor). If you search for X86_ARCH_CMOVE you see that m_GEODE is one of the #defines that implements it. However for now there probably isn't a way which fits the wiki page's definition of safe.
- Bssteph 03:52, 24 April 2007 (UTC)
- That file merely fails to exclude m_GEODE. It doesn't explicitly include it, which makes me a little uneasy. I'm still not convinced that the SC1100 is an i686-class processor, so I'll try -march=pentium-mmx, which the Safe CFLAGS page now recommends.
- 69.31.133.16 11:03, 13 April 2008 (UTC)
- (robink at creosotehill dot org)
[edit] Missing Itanium Variants (ia64)
I know these are few and far apart, but I have one.... So do I... can some one please look into putting these in...
I was just looking at these and noticed there are no details for these processors. But also, there is hardly anything magical about them. There are only two actual architectures: itanium (aliased by itanium1 and merced) and itanium2 (aliased by mckinley). Also, the architecture ABI does not require the use of a frame pointer, so you do not need to explicitly use -fomit-frame-pointer. There are a lot of other arch-specific options, but changing the defaults of most of them either conflicts with the ABI or is only useful on HPUX machines. As such, here is a preliminary set of CFLAGS (nothing very surprising). If no one finds objection to these, they can be added for completeness:
[edit] Itanium
CHOST="ia64-unknown-linux-gnu"
CFLAGS="-march=itanium -O2 -pipe"
CXXFLAGS="${CFLAGS}"
[edit] Itanium2
CHOST="ia64-unknown-linux-gnu"
CFLAGS="-march=itanium2 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
[edit] pentium4 or prescott?
My /proc/cpuinfo shows:
vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
According to the cpu family and model I should use -march=pentium4, but according to the "model name" should I use -march=prescott? (as it has 3.00GHz and not 3000MHz written, like in the pentium4 model name..?)
- Look in the flags section for "pni" (Prescott New Instructions). If you see pni, then your processor is a Prescott-core Pentium 4, and also supports the SSE3 instruction set (so feel free add -msse3 to your CFLAGS).
- 68.9.143.126 01:58, 15 July 2007 (UTC)
[edit] http://gcc.gnu.org/viewcvs/*checkout*/trunk/gcc/config/i386/i386.c
This link used to be mentioned somewhere on the page, but later deleted. I consider adding it to the preface, as it is worthy when choosing what -march= to use. (search for processor_alias_table within the document) Anynone strongly against? Strohel
- I would not be averse to it… However, should we also have links for sparc, power, and alpha archs? --129.22.126.39 17:56, 13 May 2007 (UTC)
- Here’s a table for various architecture families with the file location (relative to the root of the gcc sourcetree) and the string for which to search (note that the strings, when searched for in their entirety are unique — e.g., a search for “cpu_table” might return more than one hit, but a search for “cpu_table[]” will return only one).
| Arch | File Location | String |
|---|---|---|
| x86/x86-64 | gcc/config/i386/i386.c |
processor_alias_table[] |
| POWER | gcc/config/rs6000/rs6000.c |
processor_target_table[] |
| SPARC | gcc/config/sparc/sparc.c |
cpu_table[] |
| Alpha | gcc/config/alpha/alpha.c |
cpu_table[] |
| HPPA | gcc/config/pa/pa.c |
pa_handle_option (size_t code |
| ARM | gcc/config/arm/arm-cores.def | N/A |
- Does anyone know of a way to use a viewcvs URL to highlight a certain string?--129.22.126.40 18:41, 16 May 2007 (UTC)
- Added to the main page. Feel free to update the text a move it within the page. Unfortunatelly i have no clue how to make viewcvs highlight it or to make a link to a certain line. Strohel 16:31, 12 June 2007 (UTC)
[edit] GCC 4.3 in portage
Currently I'm forced to use Windows XP due my job, but I'm planning go back to Gentoo, and I'm planning to do so just after GCC 4.3 gets to portage, since I have Intel Core 2 Duo CPU and I walt mtune=core2 :) So my question is WHEN GCC 4.3 will be in portage? (Approximately).
After it got stable, as in: After there is a GCC 4.3 _release_ and no dev-only versions.
-Should be sometime soon. Check out the GCC page.
Current release series: GCC 4.3.0
Status: 2008-03-06 (regression fixes and docs only).
Serious regressions. All regressions.
Previous release series: GCC 4.2.3
Status: 2008-02-02 (regression fixes and docs only).
Serious regressions. All regressions.
Active development: GCC 4.4.0 (changes)
Status: 2008-03-03 (Stage 1).
Serious regressions. All regressions.
[edit] ==
isn't there march core2 in 4.2.3 that was newly released? from the changelog '-mtune=generic can now be used to generate code running well on common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel Core 2.' http://gcc.gnu.org/gcc-4.2/changes.html
[edit] Sempron in 32bit: k8?
In the section Sempron/Sempron64, it says:
Sempron64 - 32 bit
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=k8 -msse3 -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
For CFLAGS, -march=k8 is given. Is that right for 32bit code? I doubt that. --A.Skwar 18:57, 28 January 2008 (UTC)
- Yes it is correct.
[edit] Core Solo Celeron (Conroe-L)
I own a Celeron 420 as well as the new Celeron 220, both of them have cpu family 6 but model 22 rather than model 14 as stated in the article.
cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 22 model name : Intel(R) Celeron(R) CPU 420 @ 1.60GHz stepping : 1 cpu MHz : 1599.857 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3201.59 clflush size : 64
cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 22 model name : Intel(R) Celeron(R) CPU 220 @ 1.20GHz stepping : 1 cpu MHz : 1200.110 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc up pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm bogomips : 2401.44
[edit] Core 2 Duo -march=nocona
Well i tried: CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CXXFLAGS="${CFLAGS}"
on my dell vostro 1500, it is a core 2 duo, and the nocona just kills my systme if i emerge gcc with this set, gcc cant not make executables after it, this is with gcc 4.1.2 and 4.1.1
BtW i am running Gentoo 64bit
so i think this is not a safe cflag to set.
- I'm on a Sager NP9261 Core 2 Quad (Single die with 2x Core 2 Duo's) and haven't had any problems with this.
-ibm t61 with a t8100 Penryn c2d. Same problem as above. gcc cant compile executables.
-It actually looks like it was a problem with expat i did a emerge gettext expat and things seem to be fine. clean install from install-amd64-minimal-2007.0
[edit] is -fweb safe?
is setting the cflag -fweb safe for daily use(no debugging) or not?
[edit] C3 Nehemiah can't execute C3 Samuel/Ezra code and vice versa
This statement is incorrect: "If you must be compatible with all VIA C3 versions, do not use the settings in this section and instead use the flags in the C3 entry below."
When using -march=c3 you will enable 3dnow, and that's something the c3-2 processor is lacking, just as the c3 can't execute the SSE instructions of the c3-2. When compiling for both c3 and c3-2 you should instead use -march=i586.
