From: Grant <emailgrant@gmail.com>
To: Gentoo mailing list <gentoo-user@lists.gentoo.org>
Subject: Re: [gentoo-user] Lowest common denominator compile
Date: Tue, 5 Sep 2017 20:28:20 -0700 [thread overview]
Message-ID: <CAN0CFw0xrkvErbUkN62k81f4DCkL0vQyEybJU05KBwWa+JNMqQ@mail.gmail.com> (raw)
In-Reply-To: <CAN0CFw2YEasR9Kpp2OWGqat2_P4Oi+HVPA6p9h7uZ1FDcnKuCQ@mail.gmail.com>
>>> Now I'm running into "trap invalid opcode" errors on the older
>>> systems. Can I disable some of the newer CPU instruction sets on the
>>> master laptop when compiling to hopefully generate binaries that will
>>> work on the older systems?
>>
>> Yes. You need to find out CPU_FLAGS_X86 and "-march=" values the
>> machines have, and use that in make.conf. Run the commands...
>>
>> cpuinfo2cpuflags-x86
>> gcc -c -Q -march=native --help=target | grep march=
>>
>> ...on the target machines. This will tell you what "native" is and
>> what CPU_FLAGS_X86 values to use.
>>
>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options
>> lists available "march=" options, and what instruction sets they support.
>> E.g. my old core2 desktop shows...
>>
>> [d531][waltdnes][~] cpuinfo2cpuflags-x86
>> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3"
>>
>> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march=
>> -march= core2
>>
>>
>> Unless the laptops are really old, you can probably get away with...
>> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
>>
>> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use
>> a "march=" that implements the "movbe" instruction.
>>
>> booby trap 2) If you throw in any AMD-based machines proceed with care.
>>
>> Can you post the output of...
>> gcc -c -Q -march=native --help=target | grep march=
>> ...for all the target machines?
>
>
> Let's see how -mtune=native goes and resort to the above if necessary.
> It doesn't look too bad though.
emerge -e world has finished and pushed and -mtune=native seems to
have solved the issue for now.
- Grant
next prev parent reply other threads:[~2017-09-06 3:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-04 19:39 [gentoo-user] Lowest common denominator compile Grant
2017-09-04 20:16 ` [gentoo-user] " Grant
2017-09-04 20:27 ` Alan McKinnon
2017-09-04 20:55 ` Grant
2017-09-04 21:20 ` Alan McKinnon
2017-09-05 0:01 ` Grant
2017-09-05 15:07 ` Alan McKinnon
2017-09-06 3:31 ` Grant
2017-09-05 1:54 ` Ian Zimmerman
2017-09-05 13:54 ` Grant
2017-09-05 14:39 ` Ian Zimmerman
2017-09-05 0:53 ` R0b0t1
2017-09-05 8:37 ` [gentoo-user] " Walter Dnes
2017-09-05 13:53 ` Grant
2017-09-06 3:28 ` Grant [this message]
2017-09-06 3:37 ` R0b0t1
2017-09-06 3:43 ` Grant
2017-09-06 4:32 ` R0b0t1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN0CFw0xrkvErbUkN62k81f4DCkL0vQyEybJU05KBwWa+JNMqQ@mail.gmail.com \
--to=emailgrant@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox