On Sunday, March 22, 2015 10:03:01 AM Mike Gilbert wrote: > On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez > <frodriguez.develo...@outlook.com> wrote: > > On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote: > >> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes <waltd...@waltdnes.org> wrote: > >> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul - > > mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno- bmi2 - > > mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm - mno- > > hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx - mfxsr > > -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line- > > size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector - mfpmath=sse - > > fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind- tables" > >> > > >> > Is that correct (assuming that's my output)? > >> > > >> > >> I should warn you against including all of those -mno-xxx flags. This > >> has been known to break the build process for packages like chromium, > >> which always wants to build with SSE4 support and toggles it off at > >> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use > >> macros that are not defined. > >> > > > > Isn't it possible that removing it for all packages would cause a more subtle > > problem with another faulty ebuild (like a program crashing due to an illegal > > instruction)? > > Passing -march=atom should be sufficient to ensure that you don't get > any illegal instructions. The -mno-XXX flags are redundant, and MOSTLY > harmless. You got me curious as to why they're there being redundant and I think I found out why.
I looked at the code (gcc/config/i386/driver-i386.c) and there is a very slim chance that the -march reported by gcc when using -march=native will not be the most appropriate. In some cases it's guessed based on the features reported by the CPU but on other cases it trusts the model number and Intel lists several Atom server CPUs and SoCs with no extensions at all (I have no idea what they report themselves like or if their specs are right). All the - mxxx and -mno-xxx flags are determined by the features reported by the CPU so no chance of error there (save from a CPU bug). I guess gcc devs are careful when using the model numbers (Intel lists 3 for Atoms, gcc uses only two so that may account for the models I mentioned) but the chance of error is there. The -mno-xxx flags would safeguard against it. -- Fernando Rodriguez
