Description
Kenton Groombridge
2024-01-12 17:38:23 UTC
Created attachment 882118 [details]
build.log.xz
Some initial thoughts: * You shouldn't need -march *and* -mtune if they're both for =native (-mtune should be obsolete then). * Could you expand what 'native' is on your machine? (https://wiki.gentoo.org/wiki/GCC_ICE_reporting_guide#Expand_-march.3Dnative.2C_exact_gcc_version_and_other_system-specific_options) ** app-misc/resolve-march-native output may also be helpful * Could you try to grab config.log + build.log from glibc with both good/bad? You can do this using 'ebuild /path/to/glibc-1.2.3.4.ebuild clean configure' and then poking around in the workdir. * It may also be helpful if you could provide a good and bad binary -- perhaps even if you did 'ebuild .. clean install' (note that this *won't* merge to your live filesystem, as that needs '... merge') and then just tarball the good + bad workdirs, so we can compare the two. Created attachment 882127 [details]
Expanded native
Created attachment 882128 [details]
Build log with -march=generic -mtune=generic
Created attachment 882129 [details]
./glibc-2.38-r9/work/build-x86-x86_64-pc-linux-gnu-nptl/config.log with -march=generic -mtune=generic
Created attachment 882130 [details]
./glibc-2.38-r9/work/build-amd64-x86_64-pc-linux-gnu-nptl/config.log with -march=generic -mtune=generic
Created attachment 882131 [details]
./glibc-2.38-r9/work/build-x86-x86_64-pc-linux-gnu-nptl/config.log with -march=native -mtune=native
Created attachment 882132 [details]
./glibc-2.38-r9/work/build-amd64-x86_64-pc-linux-gnu-nptl/config.log with -march=native -mtune=native
Created attachment 882133 [details]
libc.so.6 with -march=native -mtune=native
Created attachment 882134 [details]
libc.so.6 with -march=generic -mtune=generic
Think I got all you requested. Hopefully provided in a way that is easy to work with. I noticed in my first post, that the second nm command says "showing the missing symbol" as it should read "showing the correct symbol". Just got a little happy with copy/paste. Does it work fine if you enable USE=multiarch? (In reply to Ionen Wolkens from comment #13) > Does it work fine if you enable USE=multiarch? Yes it does. Can reproduce on a 7840U (framework 13) as well. W/ march=native, gcc throws undefined symbol for wcsncat. However, w/ march=generic or even march=znver4, the issue is resolved. Created attachment 889409 [details, diff]
Expand -march=native, exact gcc version and other system-specific options
Added output for `for t in param target optimize optimizer; do cmd="gcc -Q --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); done` on 7840U
I'm also seeing this same problem with -march=native on an Intel Xeon Gold 6234 (cascade lake). It shows up specifically building dev-lang/python-3.10.14. Something went wrong with the attachments. $ for a in 882130 882132 882129 882131 882133 882134; do echo "$a:" "$(curl -L --no-progress-meter "https://bugs.gentoo.org/attachment.cgi?id=$a" | sha1sum)"; done 882130: bffd25325297c5972e045e28e48f6b6ec6eb7723 - 882132: bffd25325297c5972e045e28e48f6b6ec6eb7723 - 882129: 5744525b7d4830212c212b401c11ca40278c8d37 - 882131: 5744525b7d4830212c212b401c11ca40278c8d37 - 882133: f0797dac61a24e3810c2f3a0890c919e88779d1f - 882134: f0797dac61a24e3810c2f3a0890c919e88779d1f - So, unfortunately, all logs and data we currently have here are about -march=generic; there is essentially nothing about -march=native. Created attachment 892414 [details]
./glibc-2.38-r9/work/build-x86-x86_64-pc-linux-gnu-nptl/config.log with -march=native -mtune=native
Created attachment 892415 [details]
./glibc-2.38-r9/work/build-amd64-x86_64-pc-linux-gnu-nptl/config.log with -march=native -mtune=native
Created attachment 892416 [details]
build.log.xz with -march=native -mtune=native
Reattached corrupted files. I have updated glibc and gcc since reporting this: sys-libs/glibc-2.39-r5 sys-devel/gcc-13.2.1_p20240503 I can provide a recent emerge --info if you want. I didn't think it was necessary. Thanks for the full report! The issue occurs with -march=x86-64-v4 or when -march=native enables all x86-64-v4 features. This is a glibc bug, I've submitted a patch upstream to address the issue: https://inbox.sourceware.org/libc-alpha/20240507182502.3820027-1-gabifalk@gmx.com/T/#u |