Both with and without USE=custom-cflags (!), the CFLAGS=" ... -march=native ..." in my make.conf gets replaced by "-m64". This is a *very* bad idea, because -m64 and no -march causes gcc to generate code restricted to the most basic x86-64 instruction set (common subset of intel p4/nocona and amd/k8), ignoring all the instruction set improvements made in the last 20 years, ignoring most of the capabilities of my i9-9xxx. The ebuild preserves my -mtune, but -mtune without -march is almost useless. -march, if specified, must be preserved for non-cross builds, both with and without USE=custom-cflags. Reproducible: Always
sys-libs/glibc-2.30-r2 keeps "-march=native" for me. Without USE flag "custom-cflags" set.
(In reply to Chris from comment #1) > sys-libs/glibc-2.30-r2 keeps "-march=native" for me. Without USE flag > "custom-cflags" set. It does not for me. Check second attachment of bug 700234 (taken from my system with USE=-custom-cflags): In the "System Settings" section, its says "CFLAGS="-march=native ...". In the "Package Settings", there is no "-march". In the meantime, I've successfully built with USE=custom-cflags, and the "Package Settings" also say sys-libs/glibc-2.30-r2::gentoo was built with the following: USE="(crypt) custom-cflags gd (split-usr) (static-libs) -audit -caps (-cet) -compile-locales -doc -headers-only -multiarch (-multilib) -nscd -profile (-selinux) -ssp -suid -systemtap -test (-vanilla)" CFLAGS="-mtune=native -msahf -O3 -fomit-frame-pointer -fsched-pressure -fgcse-after-reload -flive-range-shrinkage -fweb -ftracer -fivopts -ftree-loop-im -frename-registers -fstdarg-opt -ggdb -maccumulate-outgoing-args -pipe" CXXFLAGS="-mtune=native -msahf -O3 -fomit-frame-pointer -fsched-pressure -fgcse-after-reload -flive-range-shrinkage -fweb -ftracer -fivopts -ftree-loop-im -frename-registers -fstdarg-opt -ggdb -maccumulate-outgoing-args -pipe" FEATURES="userpriv pid-sandbox assume-digests sfperms binpkg-logs config-protect-if-modified preserve-libs distlocks unknown-features-warn unmerge-orphans usersandbox news keeptemp collision-protect binpkg-dostrip sandbox strict merge-sync nostrip keepwork fixlafiles unmerge-logs binpkg-docompress ipc-sandbox protect-owned ebuild-locks multilib-strict network-sandbox userfetch noclean usersync parallel-fetch" LDFLAGS="-mtune=native -msahf -O3 -fomit-frame-pointer -fsched-pressure -fgcse-after-reload -flive-range-shrinkage -fweb -ftracer -fivopts -ftree-loop-im -frename-registers -fstdarg-opt -ggdb -maccumulate-outgoing-args -pipe -fuse-ld=bfd" No -march...
(In reply to Klaus Kusche from comment #0) > Both with and without USE=custom-cflags (!), > the CFLAGS=" ... -march=native ..." in my make.conf gets replaced by "-m64". Please provide the build.log and 'emerge --info' outputs. > This is a *very* bad idea, because -m64 and no -march causes gcc to generate > code restricted to the most basic x86-64 instruction set (common subset > of intel p4/nocona and amd/k8), ignoring all the instruction set improvements > made in the last 20 years, ignoring most of the capabilities of my i9-9xxx. This is not true. glibc has a mechanism to enable optimised versions of operations regardless of passed in -march= flags. > The ebuild preserves my -mtune, but -mtune without -march is almost useless. > > -march, if specified, must be preserved for non-cross builds, > both with and without USE=custom-cflags. I don't consider -march= flags to be safe for glibc or gcc. USE=custom-cflags is the only place where we allow extreme CFLAGS.
(In reply to Sergei Trofimovich from comment #3) > (In reply to Klaus Kusche from comment #0) > > Both with and without USE=custom-cflags (!), > > the CFLAGS=" ... -march=native ..." in my make.conf gets replaced by "-m64". > > Please provide the build.log and 'emerge --info' outputs. > > > This is a *very* bad idea, because -m64 and no -march causes gcc to generate > > code restricted to the most basic x86-64 instruction set (common subset > > of intel p4/nocona and amd/k8), ignoring all the instruction set improvements > > made in the last 20 years, ignoring most of the capabilities of my i9-9xxx. > > This is not true. glibc has a mechanism to enable optimised versions of > operations regardless of passed in -march= flags. > > > The ebuild preserves my -mtune, but -mtune without -march is almost useless. > > > > -march, if specified, must be preserved for non-cross builds, > > both with and without USE=custom-cflags. > > I don't consider -march= flags to be safe for glibc or gcc. > > USE=custom-cflags is the only place where we allow extreme CFLAGS. ... such as -funroll-loops and -fomg-optimze! :D
(In reply to Chris from comment #4) > ... such as -funroll-loops and -fomg-optimze! :D I'm afraid I don't understand point you are trying to make. Can you express it more explicitly?
(In reply to Sergei Trofimovich from comment #5) > (In reply to Chris from comment #4) > > ... such as -funroll-loops and -fomg-optimze! :D > > I'm afraid I don't understand point you are trying to make. Can you express > it more explicitly? Pretty much the same point as in this article: https://wiki.gentoo.org/wiki/GCC_optimization#But_I_get_better_performance_with_-funroll-loops_-fomg-optimize.21
(In reply to Sergei Trofimovich from comment #3) > (In reply to Klaus Kusche from comment #0) > > Both with and without USE=custom-cflags (!), > > the CFLAGS=" ... -march=native ..." in my make.conf gets replaced by "-m64". > > Please provide the build.log and 'emerge --info' outputs. I will attach them. > > This is a *very* bad idea, because -m64 and no -march causes gcc to generate > > code restricted to the most basic x86-64 instruction set (common subset > > of intel p4/nocona and amd/k8), ignoring all the instruction set improvements > > made in the last 20 years, ignoring most of the capabilities of my i9-9xxx. > > This is not true. glibc has a mechanism to enable optimised versions of > operations regardless of passed in -march= flags. But only for specific functions with manually coded asm or builtins. Code generated by gcc from plain C source will never use any feature above -march. > > The ebuild preserves my -mtune, but -mtune without -march is almost useless. > > > > -march, if specified, must be preserved for non-cross builds, > > both with and without USE=custom-cflags. > > I don't consider -march= flags to be safe for glibc or gcc. > > USE=custom-cflags is the only place where we allow extreme CFLAGS. I strongly disagree. -march is not extreme. -march is one of the most basic and fundamental gcc flags, it defines the target architecture. The ebuild should always preserve it, I can't imagine any reason which would justify stripping -march. It should always be safe. If -march breaks things, this is a high-pri gcc bug.
Created attachment 596438 [details] emerge --info glibc
Created attachment 596440 [details] emerge glibc log
(In reply to Klaus Kusche from comment #7) > > > This is a *very* bad idea, because -m64 and no -march causes gcc to generate > > > code restricted to the most basic x86-64 instruction set (common subset > > > of intel p4/nocona and amd/k8), ignoring all the instruction set improvements > > > made in the last 20 years, ignoring most of the capabilities of my i9-9xxx. > > > > This is not true. glibc has a mechanism to enable optimised versions of > > operations regardless of passed in -march= flags. > > But only for specific functions with manually coded asm or builtins. > Code generated by gcc from plain C source will never use any feature above > -march. True. > > > The ebuild preserves my -mtune, but -mtune without -march is almost useless. > > > > > > -march, if specified, must be preserved for non-cross builds, > > > both with and without USE=custom-cflags. > > > > I don't consider -march= flags to be safe for glibc or gcc. > > > > USE=custom-cflags is the only place where we allow extreme CFLAGS. > > I strongly disagree. > -march is not extreme. > -march is one of the most basic and fundamental gcc flags, > it defines the target architecture. > The ebuild should always preserve it, > I can't imagine any reason which would justify stripping -march. > It should always be safe. > If -march breaks things, this is a high-pri gcc bug. I think I misinterpreted strip-flags. It should not strip away -march from glibc. Given that won't filter -march= today I won't introduce a new filter until we get more breakage reports. Your (looks like accidental) filtering needs to be investigated.
(In reply to Sergei Trofimovich from comment #10) > I think I misinterpreted strip-flags. It should not strip away -march from > glibc. > > Given that won't filter -march= today I won't introduce a new filter until > we get more breakage reports. > > Your (looks like accidental) filtering needs to be investigated. I don't think it's accidental. Check the ebuild: In function setup_target_flags, case amd64, there is an if with " filter-flags '-march=*' ". And the log I attached contains a line "Auto adding -march=x86-64 to CFLAGS_x86 #185404", which indicates that this "if" actually gets executed.
(In reply to Klaus Kusche from comment #11) > (In reply to Sergei Trofimovich from comment #10) > > I think I misinterpreted strip-flags. It should not strip away -march from > > glibc. > > > > Given that won't filter -march= today I won't introduce a new filter until > > we get more breakage reports. > > > > Your (looks like accidental) filtering needs to be investigated. > > I don't think it's accidental. Check the ebuild: > In function setup_target_flags, case amd64, there is an if with > " filter-flags '-march=*' ". > > And the log I attached contains a line > "Auto adding -march=x86-64 to CFLAGS_x86 #185404", > which indicates that this "if" actually gets executed. It is not supposed to fail.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8045956db286fac4cf3e6e0a03d5464d7049f889 commit 8045956db286fac4cf3e6e0a03d5464d7049f889 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-11-16 21:41:53 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-11-16 21:41:53 +0000 sys-libs/glibc: expose errors in sync primitives checks In bug #700232 CFLAGS_x86 mis-detects unsupported sync primitives. That triggers accidental -march=* filter-out. This change should expose actual built failure. Bug: https://bugs.gentoo.org/700232 Package-Manager: Portage-2.3.79, Repoman-2.3.18 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.30-r2.ebuild | 6 +++--- sys-libs/glibc/glibc-9999.ebuild | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
Please apply https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8045956db286fac4cf3e6e0a03d5464d7049f889 locally (or sync past it) and upload new build.log. I hope it will expose exact reason of build failure. Our main problem is to affect CFLAGS_amd64 when we care only about CFLAGS_x86 sanity. But it probably is not related to bad -march=*.
Created attachment 596450 [details] Part of full emerge log showing the do_compile_test error
(In reply to Sergei Trofimovich from comment #14) > I hope it will expose exact reason of build failure. It does. I uploaded the few lines showing the problem. If you check the two gcc calls closely, you will notice that the gcc options contain both -m64 and -m32, -m32 being second and overruling -m64 (hence, gcc generates a 32 bit .o). Then, of course, linking fails (I'm a pure 64 bit system, no multilib). So the main question is: Where does the -m32 come from and why? (my /etc/portage does not contain any -m32) And a second question is: The gcc command line in the test contains both -march=native (mine) and -march=x86-64 (definitely not mine). Is this intended / expected?
Oh, it's a USE=-multilib system. -m32 comes from CFLAGS_x86 (profiles). As written the test is not valid. It assumes to be called only from ABI=x86 context, but there are no guards around it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=525bc6c0fef5bc316812df10a93dceafdfe25e16 commit 525bc6c0fef5bc316812df10a93dceafdfe25e16 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-11-17 10:41:08 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-11-17 10:42:00 +0000 sys-libs/glibc: mangle bad -march= only for ABI=x86 Normally setup_target_flags() attempts to guard against too conservative (or missing) -march= value by chacking if sync primitives can be compiled. If it can't be compiled glibc assumes -march= value to be too low. Unfortunately, test always runs against 32-bit ABI without checking if current ABI is actually 32-bit. This causes the test mis-fire on USE=-multilib ARCH=amd64 systems. Sweep workaround under ABI=x86 case. Reported-by: Klaus Kusche Closes: https://bugs.gentoo.org/700232 Package-Manager: Portage-2.3.79, Repoman-2.3.18 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.30-r2.ebuild | 5 ++--- sys-libs/glibc/glibc-9999.ebuild | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-)
Works fine. Thanks for the fast solution!
