Talk:Safe CFLAGS
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 09:19, 5 November 2024 (UTC) :: Your reply ~~~~
This page was improperly translated to Italian. It would be helpful if someone who can do Italian translations could use the content from this page to recreate an Italian translation using the standard wiki translation framework (click translation link at top of this page). See Help:Translating.
The aim of this page is to create an alternative to the old gentoo-wiki.com Safe Cflags article. 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 the old gentoo-wiki.com Safe Cflags article very useful and have referred to it for years. However, I've recently noticed that the Handbook no longer links to the old gentoo-wiki.com Safe Cflags article 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: 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.
See 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)
- If this is still important and has not been merged into the article, please update the article with the findings. Thank you! --Maffblaster (talk) 23:56, 10 January 2022 (UTC)
Missing recommendation for Atom N280
CFLAGS for Intel Atom (Intel Atom® Processor N280) missing.
--Kreyren (talk) 17:56, 15 September 2018 (UTC)
- We'll wait on the community to update it. Thanks. --Maffblaster (talk) 23:32, 10 January 2022 (UTC)
Revision of Note in section "Automatic CPU detection by tools"
Please revise your English in the Note of section "Automatic CPU detection by tools". This is an important Note and hard to understand correctly. Massimo B. (talk) 07:09, 1 March 2019 (UTC)
- The section has been revised as requested. Hope this helps! See Special:Diff/991192/1042528. --Maffblaster (talk) 23:35, 10 January 2022 (UTC)
How to maintain this page and keep it readable
I thought about adding my new J5005 processor to this list, but it seems a never ending task to try to keep up with all new CPU releases. Also, the format chosen here would make the page very long. Maybe a table might be more suitable? Something like:
| Micro architecture | CPU family | model | example model names | Safe CFLAGS |
|---|---|---|---|---|
| Goldmont plus | 6 | 122 | Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz | CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=goldmont-plus -O2 -pipe" CXXFLAGS="${CFLAGS}" |
| Skylake Kaby Lake Kaby Lake R |
6 | 94 | Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz | CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=skylake -O2 -pipe" CXXFLAGS="${CFLAGS}" |
| Haswell | 6 | 60 | Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz |
CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=haswell -O2 -pipe" CXXFLAGS="${CFLAGS} |
| Ivy Bridge | 6 | 58 | Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz Intel(R) Pentium(R) CPU G2020 @ 2.90GHz |
CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=ivybridge -O2 -pipe" CXXFLAGS="${CFLAGS} |
Just an idea. Hfern (talk) 08:11, 21 December 2019 (UTC)
- Thank you for the suggestion, Hfern . I do like the improved look on the output. The advantage of this display format is that it looks nicer for readers, however one disadvantage is that it is not possible to click on the section headers in the TOC (table of contents) to jump to the different micro-architectures. For example, it is very functional to be able to link directly to Safe_CFLAGS#Haswell or Safe_CFLAGS#Ryzen_.28Zen_family.29 from other articles. Linking can likely accomplished with ID attributes, however the ID attributes not show up in the TOC on this article. My suggestion is to leave it as-is for the present for the sake of simple(er)/better navigation... Since this discussion has been open for longer than year and no one else has weighted in, I will close this discussion. --Maffblaster (talk) 16:42, 11 January 2022 (UTC)
CPU identification and CFLAGS for Raspberry Pi
I tried to run
gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 | grep mtune
on a Raspberry Pi 400 (nearly the same as Pi 4B) and get nothing. Which command(s) can be helpful on a Pi400?
The Pis report as BCM2835 on the mainstream kernels. https://forums.raspberrypi.com/viewtopic.php?t=188544#p1188136 Maybe a hint could be added.
Jens3 (talk) 16:59, 10 January 2022 (UTC)
- Replacing grep mtune by grep march leads to:
- gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 | grep march
- /usr/libexec/gcc/aarch64-unknown-linux-gnu/11.2.0/cc1 -E -quiet -v /dev/null -o /dev/null -mlittle-endian -mabi=lp64 -march=armv8-a+crc -dumpdir /dev/ -dumpbase null
- Jens3 (talk) 17:13, 10 January 2022 (UTC)
- Have you tried the excellent script app-misc/resolve-march-native? Don't know how well it works on ARM{,64}, but works good on AMD64. --Grknight (talk) 17:20, 10 January 2022 (UTC)
- app-misc/resolve-march-native returns: -march=armv8-a+crc. I am unsure, if crc is optional for armv8-a but the result looks quite good.
- Since the suggestion was taken and seemed to be looking correct, we will mark this ticket has resolved. Thank you, Brian Evans (Grknight) for answer the question. I have also added a section in the article mentioning this alternative method. See Special:Diff/1042563/1042564. --Maffblaster (talk) 21:04, 11 January 2022 (UTC)