Re: [gentoo-user] Lowest common denominator compile

[Walter Dnes]

On Mon, Sep 04, 2017 at 12:39:02PM -0700, Grant wrote
> 
> 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?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Ruby - 3 versions - seriously????

[konsolebox]

On Tue, Sep 5, 2017 at 4:32 AM, Marvin Gülker  wrote:
> Real breaking
> changes of documented behaviour like the Bignum/Fixnum one are rare, and
> the effects are moderate.

This isn't even "breaking" yet. Only deprecated.

-- 
konsolebox

Re: [gentoo-user] Re: High resolution on a 13 inch screen

[Grant]

>> > and indeed XFCE doesn't seem to have very good support for this.
>> > Maybe you can find some of the settings listed there useful though.
>> >
>> > Other than that, if you want working DPI scaling, you'll have much
>> > better luck with KDE 5 / Plasma.
>>
>>
>> Won't I freak out if I'm an xfce4 guy and I try to switch to KDE?  Is
>> there a better choice for HiDPI migration for people who like xfce4?
>
> I'm using XFCE with a 140 DPI display and it's working fine.


How high is your res?  This laptop has a native res of 3200x1800 so
that's what I *should* be using with DPI set a lot higher than 140 I
believe, but when it gets that high things get weird.  However I'm not
sure how much of that can be alleviated by the DE.

- Grant

Re: [gentoo-user] Re: High resolution on a 13 inch screen

[Grant]

>> Is there a way to digitally discover the true height and width of your
>> screen in mm?
>
>
> If you know the shadow mask/dot pitch [1] or the real pixel per inch of your
> screen, then calculate it. This way you see if software reports wrong
> values.


Got it:

http://pixensity.com/list/dell-xps-13-4331/


> BTW: X supports -dpi parameter/option. I use it in my xserverrc (xinit
> server script) configuration and the Xorg.0.log reports the correct and
> prior calculated values.


I think I read that there is no xorg.conf directive for DPI.  But X
should get it right if I use:

DisplaySize 294 166

- Grant

Re: [gentoo-user] Lowest common denominator compile

[Grant]

>> 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.

Thanks,
Grant

Re: [gentoo-user] Re: Lowest common denominator compile

[Grant]

>> ansible does sound pretty cool.  I'll check it out if I outgrow my
>> script but as long as I can keep using Dell XPS 13 laptops I don't
>> think it will have any trouble scaling.
>
> For those dug in minimalists among us, there is also app-admin/cdist.


Have you tried ansible?

- Grant

[gentoo-user] Re: Lowest common denominator compile

[Ian Zimmerman]

On 2017-09-05 06:54, Grant wrote:

> Have you tried ansible?

ansible was in use at one of my jobs.

I feel that it is overkill for my personal use, and possibly for yours.

OTOH, your case _is_ different from mine: I don't admin PCs for other
folks to use.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Re: Lowest common denominator compile

[Alan McKinnon]

On 05/09/2017 02:01, Grant wrote:
 This is exactly the use-case ansible was designed for: declarative,
 idempotent, predictable management of a fleet of machines that may or
 may not be around when you feel like updating something (so it catches
 up later), and needs only sshd and python to do it's magic :-)
>>>
>>> ansible does sound pretty cool.  I'll check it out if I outgrow my
>>> script but as long as I can keep using Dell XPS 13 laptops I don't
>>> think it will have any trouble scaling.
>>
>>
>> Allow me a few moments to convince you more :-)
>>
>> Maybe you don't need it right this minute, but your current method will
>> become less and less workable with time, and when you feel that maybe
>> you ought to do it differently, you might remember this conversation.
>>
>> ansible works like you do - ssh's into a host, and does what needs
>> doing. It figures out what to do the same way you do, by having a clear
>> picture of what should be and making the host that way. It's very much
>> like a proxy for you.
>>
>> The difference comes in when you observe that with ansible you don't
>> have to deal with the details of HOW to do something (the shipped
>> modules already deal with all of that), you only concern yourself with
>> WHAT you want to accomplish.
>>
>> If you only use ansible to basically run ssh in a for loop, then it's a
>> waste of the setup effort. But let's say Dell retire or change those
>> XPS13s dramatically. 4 of yours wear out, and you buy 8 Precisions.
>> Bugger, they have different hardware and the chipset running the SSDs
>> has a different drive. The GPU, the wifi NIC, these things all drift
>> with time. Then you figure you want 2 management Precisions, plus
>> your's, the wife's and the workshop manager's laptops need extra stuff;
>> and the plebs can stay the same on the XPS.
>>
>> And your script gets out of hand real quick (we've all been there). How
>> do you detect that some is a Precision and do appropriate actions in a
>> nasty script? It's not easy.
>> Ansible does all that for you upfront out the box. It always knows what
>> it's working on (thanks to a module called setup) and catering for
>> inevitable differences is trivial to handle. With none of the downsides
>> to copying entire tree structures around (like copying way too many
>> files you didn't intend to. Like /var/run...)
> 
> 
> It truly sounds great but the devil is in the details in my particular
> environment.  If I feel like I'm outgrowing my script (and maybe even
> if I don't) I'll dig into ansible.  How big of a duty is the
> implementation?

Implementation is easy, it's just another Python app with a config file.

Then there's some associated work around getting your SSH setup the way
you want it with the correct users and passwords and keys and enough
access control that you feel safe. Nothing new there, you likely already
have all that already. If not, well ssh isn't exactly new to you :-)

The bulk of the work is in thinking and planning what you want to
achieve. You have to have a very clear picture of the end goal so you
can build towards it; this part is exactly like thinking your way
through code you intend to write. This part depends on how complex your
stuff is and how many exceptions you have to the rule.

You're the only one that knows if the result will be worth while, so
like all new toys I suppose the best approach is to tinker with it a
bit, see if you like it, then decide if you think it worthwhile to proceed.

-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] bind-9.11.1_p3 error with one ipv6 host

[jens w]

2 times, one error with 1 ddns host, i have 14 ddns hosts.
ping6 martine.ddnss.org give unknown host back.
in named.log I see the hostname with added local domain.
martine.ddnss.org.lxsbbshome.tld.
this happens only at the ipv6/-record, only by this host,
not at the ipv4/A-record.
when I restart named is all ok.
Is that a bind-bug?

named.log
05-Sep-2017 04:33:04.042 queries: info: client @0x7f09800cbc20
192.168.4.77#50295 (martine.ddnss.org): query: martine.ddnss.org IN A +
(192.168.4.77)
05-Sep-2017 04:33:04.044 queries: info: client
@0x7f09800cbc20 192.168.4.77#54460 (161.25.33.95.in-addr.arpa): query:
161.25.33.95.in-addr.arpa IN PTR + (192.168.4.77)
05-Sep-2017 04:33:04.050 queries: info: client @0x7f09800cbc20
192.168.4.77#36067 (martine.ddnss.org): query: martine.ddnss.org IN
 + (192.168.4.77) 05-Sep-2017 04:33:04.050 queries: info: client
@0x7f09800cbc20 192.168.4.77#53433 (martine.ddnss.org.lxsbbshome.tld):
query: martine.ddnss.org.lxsbbshome.tld IN  + (192.168.4.77)

05-Sep-2017 04:33:16.189 queries: info: client @0x7f098060b440
192.168.4.77#39553 (lxsbbs.dynv6.net): query: lxsbbs.dynv6.net IN A +
(192.168.4.77)
05-Sep-2017 04:33:16.241 queries: info: client
@0x7f09806727e0 192.168.4.77#51797 (161.25.33.95.in-addr.arpa): query:
161.25.33.95.in-addr.arpa IN PTR + (192.168.4.77)
05-Sep-2017 04:33:16.247 queries: info: client @0x7f09806727e0
192.168.4.77#35789 (lxsbbs.dynv6.net): query: lxsbbs.dynv6.net IN 
+ (192.168.4.77)
05-Sep-2017 04:33:16.289 queries: info: client
@0x7f0980647050 192.168.4.77#39775
(7.2.a.a.1.9.e.f.f.f.7.2.0.0.a.0.0.0.0.0.1.a.9.1.1.2.f.5.2.0.0.2.ip6.arpa):
query:
7.2.a.a.1.9.e.f.f.f.7.2.0.0.a.0.0.0.0.0.1.a.9.1.1.2.f.5.2.0.0.2.ip6.arpa
IN PTR + (192.168.4.77)
05-Sep-2017 04:33:16.545 queries: info: client
@0x7f0980044f60 192.168.4.77#48239
(7.2.a.a.1.9.e.f.f.f.7.2.0.0.a.0.0.0.0.0.1.a.9.1.1.2.f.5.2.0.0.2.ip6.arpa):
query:
7.2.a.a.1.9.e.f.f.f.7.2.0.0.a.0.0.0.0.0.1.a.9.1.1.2.f.5.2.0.0.2.ip6.arpa
IN PTR + (192.168.4.77)

Re: [gentoo-user] Re: High resolution on a 13 inch screen

[Floyd Anderson]

On Di, 05 Sep 13:29:13 +
Grant  wrote:

Is there a way to digitally discover the true height and width of your
screen in mm?



If you know the shadow mask/dot pitch [1] or the real pixel per inch of your
screen, then calculate it. This way you see if software reports wrong
values.



Got it:

http://pixensity.com/list/dell-xps-13-4331/



BTW: X supports -dpi parameter/option. I use it in my xserverrc (xinit
server script) configuration and the Xorg.0.log reports the correct and
prior calculated values.



I think I read that there is no xorg.conf directive for DPI.


I mean -dpi as command line parameter/option, see `/usr/bin/Xorg -help` 
or [1]. On the same site is an example (“Tips and tricks” section) for 
startx invocation that bypass -dpi to Xorg but DisplaySize should do the 
job also.



But X should get it right if I use:

DisplaySize 294 166


Looks like a typo. I got:

   349.6462 mm × 165.6207 mm

with:

   $ bc <<<'scale=4; ppi=276.05; cx=3800; inch=25.4; cx / ppi * inch'


[1] 


--
Regards,
floyd

Re: [gentoo-user] Re: High resolution on a 13 inch screen

[Floyd Anderson]

On Di, 05 Sep 20:00:56 +
Floyd Anderson  wrote:

On Di, 05 Sep 13:29:13 +
Grant  wrote:


[…]


But X should get it right if I use:

DisplaySize 294 166


Looks like a typo. I got:

  349.6462 mm × 165.6207 mm

with:

  $ bc <<<'scale=4; ppi=276.05; cx=3800; inch=25.4; cx / ppi * inch'


Argh, my bad. Ignore the calculation above and in my previous reply. I’m 
wrong because I used 3800 px instead of 3200 px. Sorry for the noise.



--
Regards,
floyd

Re: [gentoo-user] Re: High resolution on a 13 inch screen

[wabe]

Grant  wrote:

> >> > and indeed XFCE doesn't seem to have very good support for this.
> >> > Maybe you can find some of the settings listed there useful
> >> > though.
> >> >
> >> > Other than that, if you want working DPI scaling, you'll have
> >> > much better luck with KDE 5 / Plasma.  
> >>
> >>
> >> Won't I freak out if I'm an xfce4 guy and I try to switch to KDE?
> >> Is there a better choice for HiDPI migration for people who like
> >> xfce4?  
> >
> > I'm using XFCE with a 140 DPI display and it's working fine.  
> 
> 
> How high is your res?  This laptop has a native res of 3200x1800 so
> that's what I *should* be using with DPI set a lot higher than 140 I
> believe, but when it gets that high things get weird.  However I'm not
> sure how much of that can be alleviated by the DE.

You said your screen has a size of 13". When my 4k 32" screen has 
a DPI resolution of 140dpi than your 4k screen has a resolution of 
approximately 345dpi. 
I don't see a reason why auch a high DPI value shouldn't work fine
also. 

My monitor has a resolution of 3840x2160 and an approximate screen
diagonal of 32". Xorg says that the image size is 698 x 393 mm (don't
have a tapeline handy but IIRC that's correct). That's 27.48 x 15.47 
inch. 

3840 / 27.48 = 139.74
2160 / 15.47 = 139.63

So 140 DPI seems to be a correct value for my monitor. And indeed 
font's have nearly the same size on screen as before with my old 
monitor (1920x1080, 27" 83DPI), but of course they are much sharper
now. 

I'm using "Source Code Pro 10" as default font. For the XFCE panel 
I use "Droid Sans 8" (you can configure this in ~/.gtkrc-2.0).
Antialiasing is on and Hinting is set to "Full". 

You should check what pixel color order your display has. Most 
displays use RGB, but some use an other order (my display uses BGR). 
If this value is not set correctly and you use antialiasing 
(strongly recommended) then fonts are looking fuzzy (colored edges).


As I already wrote, the DPI setting doesn't change the size of XFCE
window decorations, at least on my machine. I'm fine with the 
standard window decoration size (I use the "numix" theme for that). 
But if my display would have such a high DPI value as yours I probably
would use "Default-hdpi" or maybe even "Default-xhdpi" as theme for 
the window decorations.

The size for icons used in menus, buttons, toolbars etc. can be 
adjusted as well by modifying the theme gtkrc file. 
Maybe it could be that you can only use sizes that are available as 
bitmaps for the icon set you use. But I don't know, never checked 
this. Maybe you can also use arbitrary sizes because for many icon 
sets there exists a directory containing scalable icons in SVG format.


I would check out if it is possible to tweak your XFCE settings in 
a way that everything looks good without the need to decrease the 
Xorg resolution. 

--
Regards
wabe

Re: [gentoo-user] Lowest common denominator compile

[Grant]

>>> 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

Re: [gentoo-user] Re: Lowest common denominator compile

[Grant]

>> It truly sounds great but the devil is in the details in my particular
>> environment.  If I feel like I'm outgrowing my script (and maybe even
>> if I don't) I'll dig into ansible.  How big of a duty is the
>> implementation?
>
> Implementation is easy, it's just another Python app with a config file.
>
> Then there's some associated work around getting your SSH setup the way
> you want it with the correct users and passwords and keys and enough
> access control that you feel safe. Nothing new there, you likely already
> have all that already. If not, well ssh isn't exactly new to you :-)
>
> The bulk of the work is in thinking and planning what you want to
> achieve. You have to have a very clear picture of the end goal so you
> can build towards it; this part is exactly like thinking your way
> through code you intend to write. This part depends on how complex your
> stuff is and how many exceptions you have to the rule.
>
> You're the only one that knows if the result will be worth while, so
> like all new toys I suppose the best approach is to tinker with it a
> bit, see if you like it, then decide if you think it worthwhile to proceed.


Will do, thanks Alan.

- Grant

Re: [gentoo-user] Lowest common denominator compile

[R0b0t1]

On Tue, Sep 5, 2017 at 10:28 PM, Grant  wrote:
 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.
>

You might be interested in "-march=x86-64 -mtune=generic" though this
will mean you might miss out on some optimizations.

Re: [gentoo-user] Lowest common denominator compile

[Grant]

> 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.
>>
>
> You might be interested in "-march=x86-64 -mtune=generic" though this
> will mean you might miss out on some optimizations.


If I could miss out on optimizations, what is the advantage compared
to -mtune=native?  Better compatibility across CPUs?

- Grant

Re: [gentoo-user] Lowest common denominator compile

[R0b0t1]

On Tue, Sep 5, 2017 at 10:43 PM, Grant  wrote:
>> 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.
>>>
>>
>> You might be interested in "-march=x86-64 -mtune=generic" though this
>> will mean you might miss out on some optimizations.
>
>
> If I could miss out on optimizations, what is the advantage compared
> to -mtune=native?  Better compatibility across CPUs?
>

Well, having looked it up (again), -march will break backwards
compatibility while -mtune=native will not if you stay within a family
of processors. So, yes.

One of the finer points of -mtune is that is specifies processor cache
sizes. If this is set to an incorrect value you could get very poor
performance relative to leaving it unset (with -mtune=generic).

For the exact differences, try:

gcc -march=native -mtune=native -E -v - &1 | grep cc1
echo | gcc -dM -E - -march=native

Which will show you the expanded compilation flags and macro
definitions, respectively.