This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
Talk:Safe CFLAGS
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (
~~~~).
When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.The aim of this page is to create an alternative to this. Since we can not directly copy, I would suggest that users instead check their own CFLAGS and put them into this page so that we can build up a solid list of CPUs and their suggested CFLAGS. — The preceding unsigned comment was added by PeterWilmott (talk • contribs) 7 December 2012
--march=native
I think this page should include a chapter explaining why --march=<processor specific> would be better than --march=native, because it's confusing for new users to find these two different recommendations without any explanation which one is the "proper" way. — The preceding unsigned comment was added by Smartass (talk • contribs) 8 December 2012
- Although the page now mentions march=native, it still doesn't explain, why march=corei7 would be preferred (what are the benefits) over march=native, which may confuse many people. Smartass 15:54, 11 December 2012 (UTC)
- The use of distcc (particularly in support of *cross*-compiling) is a significant motivation for using a specific setting for -march= other than native. I have found this very useful and have referred to it for years. However, I've recently noticed that the Handbook no longer links to this and instead now refers users to GCC_optimization which uses a different procedure than that prescribed in this page. I suppose that may reflect he difference between "safe" and "optimum" See also this forum thread. brendlefly62 (talk) 17:59, 23 January 2017 (UTC)
Core 2 Duo issue
I just added a section for the Core 2 Duo, and ran into a problem that touched on your comment. Apparently setting the "-march" explicitly vs using native might effect your ability to cross compile, and it may effect what processor optimizations are enabled:
Setting -march=core2 tells gcc to enable MMX, SSE, SSE2, SSE3, SSSE3 instruction set support. (Citation: http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options ) Setting the USE variable to include "MMX, SSE, SSE2, SSE3" would then be redundant; I believe.
Some core 2 solo/duo/quad processors support sse4, sse4a, and sse4_1. I'd like to find a safe and correct way of enabling support for sse4 sse4a, and sse4.1 in the CFLAGS and/or USE for a core 2 duo that supports them.
I don't think seting these in the USE flags is the correct way. Unless I'm mistaken, only packages that support those use flags would benefit; or am I wrong about that? Also I noticed that the sse4, sse4a, and sse4_1 USE flags are not included in the global use flag list at: http://www.gentoo.org/dyn/use-index.xml Does there abscence from that list mean those use flags would have no effect?
One person who made a nice page about optimizing for the Core 2 solo/duo/quad (Citation: http://wiki.gentoo.org/wiki/Intel_Core_2 ) suggested just setting -march=native. GCC seems to recognize the sse4 instruction sets when I run "gcc -march=native -E -v - </dev/null 2>&1 | grep cc1" so setting -march=native might solve the problem. However sometimes I cross compile; and according to the Gentoo GCC optimization guide ( http://www.gentoo.org/doc/en/gcc-optimization.xml ) using native will cause problems when trying to cross compile. So many questions raised.... I should turn this into a forum post - It kind of got out of hand... To reiterate: I'd like to add to this page a safe and correct way of enabling support for sse4 sse4a, and sse4.1 in the CFLAGS/USE for a core 2 duo that supports them. Any one know a definitive way of identifying processor support for those processor optimizations; and how to enable them in GCC? Thank you! Aries97 (talk) 04:45, 15 May 2013 (UTC)
Update: Core2 processors support EM64T - aka AMD64. (Wikipedia: http://en.wikipedia.org/wiki/EM64T#Intel_64 ) For whatever reason; I had an i686 CHOST set earlier. I've tested this on my processor and changed the entry to reflect a corrected CHOST="x86_64-pc-linux-gnu". Aries97 (talk) 06:23, 28 May 2013 (UTC)
Add Intel Suggested i7 Optimizations
Suggest adding Intel's suggested optimizations someplace for i7 processors. http://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints
ie. CFLAGS="-m64 -Ofast -flto -march=native -funroll-loops"
Granted this is Safe CFLAGS, and some reference should be made to the manufacturer's suggestions. — The preceding unsigned comment was added by Roger (talk • contribs) 17 June 2013
- Please add the manufactures suggestions yourself. I'm closing this discussion because there's nothing to discuss. Also, last time I checked, using
-funroll-loopsis never a manufacturer suggestion. :P --Maffblaster (talk) 16:43, 20 April 2017 (UTC)
Section Core i3/i5/i7 & Xeon E3/E5/E7 *V2 seems to be incorrect
CFLAGS="-march=core-avx2 -O2 -pipe" is not working for my Xeon-E5 2620 which seems to be sandybridge based.
Please correct -- Tazinblack (talk) 09:39, 25. Nov. 2016
- Hi, I corrected the values. Since GCC 4.9 you should use:
CFLAGS="-march=sandybridge -O2 -pipe"
-- JackDelik (talk) 10:59, 25 November 2016 (UTC)
It's still not correct by now.
The headline says 'Haswell' and in the next line 'Core i3/i5/i7 & Xeon E3/E5/E7 *V2'. But Haswell is not V2 but V3. So this should be V3.
As far as I see V1 should be SandyBridge, V2 IvyBridge and V3 Haswell. -- Tazinblack (talk) 16:41, 25. Nov. 2016 (UTC)
- You're right, I corrected this. Be bold: you can edit the pages too :) JackDelik (talk) 16:57, 25 November 2016 (UTC)
- JackDelik +1 to you! People should be editing pages more! Looks lke this discussion is now closed, so I'm marking it as such! Thanks for the help on the wiki! --Maffblaster (talk) 16:40, 20 April 2017 (UTC)
Order of listings
I think it would be best to sort Intel and AMD sections based on release dates. Or at least approximate. I don't know about Intel, but AMD section is in somewhat random order.
Better yet, if a table format could be used... Although it might be too wide.
- AFAIK, the only "intruder" was AMD 12h which was placed directly next to the rest of A-series APUs. Now the AMD list is sorted by architecture release date. --Yuri69 (talk) 19:29, 2 May 2017 (UTC)
- Feel free to draft it up in your userspace. --Maffblaster (talk) 22:10, 9 May 2017 (UTC)
- I made several fixes to the layout. Now it seems intact layout-wise. I also changed the names to bold. Matthew Marchese (maffblaster) do you think I should put this "online"? Also should I delete those <!-- T:number --> comments? What are those even for? --Zucca (talk) 21:44, 10 May 2017 (UTC)
- I've pushed the "table-layout" out now. I also moved few things around, but the content is still the same. Now would be the time to judge the change. It it worth it or not?
- Looks fine to me. Closing discussion. --Maffblaster (talk) 03:03, 14 May 2017 (UTC)
Ryzen information deduplication?
I'd like to propose a removal of the Ryzen section and replace the contents with a link to Ryzen#GCC. I think this could be beneficial, especially now as we get more information every day regarding the segfaults. So updating only one article makes sense and is more consistent. Opinions etc please. :) --Zucca (talk) 19:00, 8 June 2017 (UTC)
- Hi Ilja Sara (Zucca) , I'd be all for either adding a link like you suggest or transcluding the section into this article. I'm generally supportive of deduplication where ever we can! :) --Maffblaster (talk) 23:52, 8 June 2017 (UTC)
i3-3xxx IvyBridge has no AES
As I had to find out after compiling qtcore 5.9.4 and being unable to start, e.g., vlc, I found out that ivybridge and previous do not support AES on i3.
https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture
Therefore, "safe flags" needs to be extended with -mno-aes for Ivy Bridge, Sandy Bridge and many Westmere. -mno-avx2 seems to be ignore by Qt, that is probably a qt bug, though.
Amend: because it is a virtual machine, I also had to add -mno-f16c and -mno-rdrnd. This is probably not related to ivy-bridge but to virtual machines (at least VirtualBox) generally.
- The RDRAND instruction is broken on some Ivy Bridge CPUs, so the
-mno-rdrndshould definitely be recommended. Technically, the RDRAND feature should work when used, however the bug prevents it from being reported as a supported instruction. Intel had documented this bug as Errata BV54, and they say it can be circumvented by an updated BIOS, assuming the motherboard manufacturer does so and the user has flashed the fixed BIOS. So we should probably advise users to do agrep rdrand /proc/cpuinfoto see if they actually need to apply the-mno-rdrndflag or not. - The full list of errata are listed here: http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf Kabili207 (talk) 17:12, 5 October 2018 (UTC)
Missing recommendation for Atom N280
CFLAGS for Intel Atom (Intel Atom® Processor N280) missing.