Regarding dertermine safe CFLAGS:
Inspired by a lecture, I gave at the workshop here (sorry, only german language):
https://forums.gentoo.org/viewtopic-t-1017200-highlight-trolug.html
Sebastian Pipping wrote a nice python-script which does the job quite well.
The package is in the tree since almost a year and is called:
app-misc/resolve-march-native
After installation you can call it e.g. with:

Hi frankenputer,
your sample output contains lots of faults regarding the CPU_FLAGS_X86="" line.
It should only contain CPU Flags which also exist as USE-Flags.

Hi Andy,

The Mihai's program detects avx512* flags which doesn't exists as USE flags at this point.
Including those existing cpu instructions that does not exists as CPU_FLAGS_X86 USE flags won't break the system.
In case they are added upstream, all users that have avx512* flags in their configs will be able to leverage them.

---

Quote:

But you don't have to fiddle this out by your own, if you would like to read the news message from:

Sebastian Pipping wrote a nice python-script which does the job quite well.
The package is in the tree since almost a year and is called:
app-misc/resolve-march-native
After installation you can call it e.g. with:
Code:
resolve-march-native -a

The Mihai's program detects avx512* flags which doesn't exists as USE flags at this point.
Including those existing cpu instructions that does not exists as CPU_FLAGS_X86 USE flags won't break the system.
In case they are added upstream, all users that have avx512* flags in their configs will be able to leverage them.

Only cause mmx is named into the vanilla make.conf, does not guaranty that it would be thrown away by the average user.
You leave it out by your kung fu, which mean that packages which makes uses of it, doesn't compile this functionality into, although you set the superior grade mmext flag.
Much more packages makes usage of mmx compared to mmext, just compare the output of:

Code:

equery h cpu_flags_x86_mmx

vs.

Code:

equery h cpu_flags_x86_mmxext

Similar for your mabm mcx16 mlzcnt msahf, these doen't exist as cpu_flags_x86 and probably never would.
Theses flags belongs to the CFLAGS, if there's a need activate (-m) or deactivate (-mno) it there.

Your claim here the 2 missing cache-size parameters, but since I found a package (openmpi), which doesn't compile successfully here on my westmere Xeon cpu if I use
the l1-cache-size= parameter, I'm not sure if leaving out the cache parameters is good or bad. How big would be the difference regarding performance? I never tested it.
In the sense of giving safe CFLAGS, it seems to be better to leave it out to me. To present safe CFLAGS is lastly the intention of this little helper script.

The power user (or worser the ricer) hast to decide by himself, how to optimize the settings stronger, but that's not what the title of such wikis reflect.

---

frankenputer wrote:

At the end of the day the user has choice, either mine gawk kung fu, Mihai's program or the Sebastian's one or the Ant P. one.

I appreciate negative and positive feedback, but can't stand next to "jump to conclusions" ones.

Only to ask GCCs CPU recognition fails sometimes, there are lots of bug reports which shows that (references at the bottom).
That's why the Safe_CFLAGS Wiki and Sebastians program tries a different approach, compiling two files with different settings and compare it afterwards, to filter out wrongly recognized flags.

Only cause mmx is named into the vanilla make.conf, does not guaranty that it would be thrown away by the average user.
You leave it out by your kung fu, which mean that packages which makes uses of it, doesn't compile this functionality into, although you set the superior grade mmext flag.

Similar for your mabm mcx16 mlzcnt msahf, these doen't exist as cpu_flags_x86 and probably never would.
Theses flags belongs to the CFLAGS, if there's a need activate (-m) or deactivate (-mno) it there.

Your claim here the 2 missing cache-size parameters, but since I found a package (openmpi), which doesn't compile successfully here on my westmere Xeon cpu if I use
the l1-cache-size= parameter, I'm not sure if leaving out the cache parameters is good or bad. How big would be the difference regarding performance? I never tested it.
In the sense of giving safe CFLAGS, it seems to be better to leave it out to me. To present safe CFLAGS is lastly the intention of this little helper script.

Never say never, also google which cpu's are supporting avx512* and when they first appeared. Also it's bad idea to enable such CFLAGS globally, as it's bad idea to use USE flags globally instead per-package USE/CFLAG.

The "big" difference is that you've not used Google, also it tells me that you have not programmed in low level language.

Same could be said for pipe, just because it ships in vanilla make.conf and is hard-coded in Sebastian's program doesn't make it "safe":

It tells the compiler to use pipes instead of temporary files during the different stages of compilation, which uses more memory. On systems with low memory, GCC might get killed. In those cases do not use this flag.

The "big" difference is that you've not used Google, also it tells me that you have not programmed in low level language.

I'll stop right here and ask any moderator/administrator to lock this thread, before some **already angry** people start insulting me and embarrass themselves even further than they are currently.

Wow,

it seems that you know more about me, than myself.

Respect, never experienced that before here, maybe because you're relative new to this outstanding forum.

It looks like you're not really interested in technical based criticism and react very emotional when you get one.
Then you blame on me on a personal basis and would try to lock the thread - not bad guy, but to late.

No need to, cause I'm not longer willing to discuss/escalate it with you in that way!
Bye._________________If you want to see a Distro done right, compile it yourself!