Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code?

[Fernando Rodriguez]

On Sunday, March 22, 2015 10:03:01 AM Mike Gilbert wrote:
> On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez
> <frodriguez.developer@×××××××.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 <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