Created attachment 537146 [details] sys-libs~glibc-2.27-r4.build.log.xz I’m wondering why “__strcspn_sse42” is involved on a machine without SSE4 capabilities. # MAKEOPTS="-j1" emerge -1vO sys-libs/glibc [ebuild U ~] sys-libs/glibc-2.27-r4:2.2::gentoo [2.27-r3:2.2::gentoo] USE="caps (multilib) -audit (-compile-locales) -doc -gd (-hardened) -headers-only -nscd -profile (-selinux) -suid -systemtap (-vanilla)" 0 KiB […] x86_64-pc-linux-gnu-gcc -m32 -Wl,-O1 -Wl,--as-needed ../sysdeps/i386/i686/multiarch/strcspn-c.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -Wundef -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -frounding-math -fstack-protector-all -march=core2 -mno-abm -mno-aes -mno-avx -mno-avx2 -mno-bmi -mno-bmi2 -mno-f16c -mno-fma -mno-fma4 -mno-fsgsbase -mno-hle -mno-lwp -mno-lzcnt -mno-movbe -mno-pclmul -mno-popcnt -mno-rdrnd -mno-rtm -mno-sse4.1 -mno-sse4.2 -mno-tbm -mno-xop -mno-xsave -mno-xsaveopt -mtune=core2 -pipe -Wstrict-prototypes -Wold-style-definition -Wa,-mtune=i686 -msse4 -ftls-model=initial-exec -U_FORTIFY_SOURCE -march=core2 -mtune=core2 -pipe -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-xsave -mno-xsaveopt -O2 -fno-strict-aliasing -I../include -I/var/tmp/portage/sys-libs/glibc-2.27-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/string -I/var/tmp/portage/sys-libs/glibc-2.27-r4/work/build-x86-x86_64-pc-linux-gnu-nptl -I../sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/i386/i686/nptl -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/x86/nptl -I../sysdeps/i386/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../sysdeps/i386/i686 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/i386 -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include /var/tmp/portage/sys-libs/glibc-2.27-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h -DTOP_NAMESPACE=glibc -o /var/tmp/portage/sys-libs/glibc-2.27-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/string/strcspn-c.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.27-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/string/strcspn-c.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.27-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/string/strcspn-c.o In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/nmmintrin.h:31:0, from ../sysdeps/x86_64/multiarch/strcspn-c.c:20, from ../sysdeps/i386/i686/multiarch/strcspn-c.c:3: ../sysdeps/x86_64/multiarch/strcspn-c.c: In function ‘__strcspn_sse42’: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/smmintrin.h:631:1: error: inlining failed in call to always_inline ‘_mm_cmpistri’: target specific option mismatch _mm_cmpistri (__m128i __X, __m128i __Y, const int __M) ^~~~~~~~~~~~ In file included from ../sysdeps/i386/i686/multiarch/strcspn-c.c:3:0: ../sysdeps/x86_64/multiarch/strcspn-c.c:99:11: note: called from here int length = _mm_cmpistri (mask, mask, 0x3a); ^~~~~~ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/nmmintrin.h:31:0, from ../sysdeps/x86_64/multiarch/strcspn-c.c:20, from ../sysdeps/i386/i686/multiarch/strcspn-c.c:3: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/smmintrin.h:631:1: error: inlining failed in call to always_inline ‘_mm_cmpistri’: target specific option mismatch _mm_cmpistri (__m128i __X, __m128i __Y, const int __M) ^~~~~~~~~~~~ In file included from ../sysdeps/i386/i686/multiarch/strcspn-c.c:3:0: ../sysdeps/x86_64/multiarch/strcspn-c.c:99:11: note: called from here int length = _mm_cmpistri (mask, mask, 0x3a); ^~~~~~ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/nmmintrin.h:31:0, from ../sysdeps/x86_64/multiarch/strcspn-c.c:20, from ../sysdeps/i386/i686/multiarch/strcspn-c.c:3: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/smmintrin.h:631:1: error: inlining failed in call to always_inline ‘_mm_cmpistri’: target specific option mismatch _mm_cmpistri (__m128i __X, __m128i __Y, const int __M) ^~~~~~~~~~~~ […] additional 260 lines of error messages are in the attached build log
Created attachment 537148 [details] emerge--info.txt
glibc has code to detect sse4 support at runtime and enable more optimised function. _mm_cmpistri is an SSE 4.2 instruction. Your CFLAGS explicitly disable it with -mno-sse4.1. You don't need to use -mno-* options for -march=core2 CPU. Check it by running: gcc -O2 -march=core2 -Q --help=target https://bugs.gentoo.org/657760#c5 change might have exposed this problem.
The problem happens here because glibc ebuild passes user-CFLAGS into CPPFLAGS. Unfortunately CPPFLAGS normally has higher precedence (pseudocode): glibc-CFLAGS += -msse4 %.o: %.c $(CC) -c $(glibc-CFLAGS) $(user-CFLAGS) $(CPPFLAGS) $< -o $@ I'll try to fix the glibc ebuild to pass $(user-CFLAGS) as part of CC as was previously suggested by upstream.
Thank you Sergei for the information and your fast response. I wrote this before your 2nd post: > glibc has code to detect sse4 support at runtime and enable more optimised function. Well, the sse4 detection seems to be not working properly. The Intel U2700 on this machine does not have SSE4 [1][2]. Also automatic detection should be disabled on Gentoo. The user is setting the CFLAGS, the user have the right to shoot in its own foot ;-) Automatic detection has no right to shoot at the user … Is the automatic detection based on parsing the CFLAGS (and ignoring the “no” prefix)? This seems to be the newest hype and in my opinion also a bad idea. CPU_FLAGS_X86 should be parsed. I think it is also a bad idea if this detection happens on binaries for a different target machine which does not support the detected optimisation. I know that I do not need the -mno-* CFLAGS but they are very effective to detect such kind of bugs. I also think they have a reason to exist (if they have been implemented upstream) and it does not hurt to provide them to the compiler as an safety net (for distcc e.g.). Automatic detection does not work properly if the host machine compiles for another target with less optimizations. I can not imagine debugging such wrongly compiled libc in my system. And if libc has a fallback (because of its importance), how many cycles does it costs? ;-) I hope, you are able to solve this bug and I wish you success. But removing -r3 (which compiled without an error on this system) was a mistake. I can not mask -r4 without downgrading to 2.26, and we all know what happens after downgrading of glibc :-) never mind, 2.27 is not stabilized and I know how to trick portage. [1] https://en.wikipedia.org/wiki/List_of_Intel_Pentium_microprocessors#%22Penryn-3M%22,_%22Penryn-L%22_(45_nm) [2] https://ark.intel.com/products/42004
(In reply to Philipp Psurek from comment #4) > > glibc has code to detect sse4 support at runtime and enable more optimised function. > > Well, the sse4 detection seems to be not working properly. The Intel U2700 > on this machine does not have SSE4 [1][2]. SSE4 autodetection happens at runtime for the final binary, not at glibc build time. To elaborate: there is more than one memcpy() variant in libc.so. Each glibc binary calls CPUID (and whatnot) and chooses fastest memcpy() for current CPU. Regardless(-ish) of the CFLAGS used to build glibc.
Using CFLAGS as part of CC/CXX would loks like that: --- a/sys-libs/glibc/glibc-2.27-r4.ebuild +++ b/sys-libs/glibc/glibc-2.27-r4.ebuild @@ -790,18 +790,17 @@ glibc_do_configure() { einfo " $(printf '%15s' ${v}:) ${!v}" done + # CFLAGS can contain ABI-specific flags like -mfpu=neon, see bug #657760 + # To build .S (assembly) files with the same ABI-specific flags + # upstream currently recommends adding CFLAGS to CC/CXX: https://sourceware.org/PR23273 + # The glibc configure script doesn't properly use LDFLAGS all the time. - export CC="$(tc-getCC ${CTARGET}) ${LDFLAGS}" + export CC="$(tc-getCC ${CTARGET}) ${CFLAGS} ${LDFLAGS}" einfo " $(printf '%15s' 'Manual CC:') ${CC}" # Some of the tests are written in C++, so we need to force our multlib abis in, bug 623548 - export CXX="$(tc-getCXX ${CTARGET}) $(get_abi_CFLAGS)" + export CXX="$(tc-getCXX ${CTARGET}) $(get_abi_CFLAGS) ${CFLAGS}" einfo " $(printf '%15s' 'Manual CXX:') ${CXX}" - # CFLAGS can contain ABI-specific flags like -mfpu=neon, see bug #657760 - # To build .S (assembly) files with the same ABI-specific flags - # upstream currently recommends adding CFLAGS to CPPFLAGS: https://sourceware.org/PR23273 - export CPPFLAGS="${CPPFLAGS} ${CFLAGS}" - einfo " $(printf '%15s' 'Manual CPPFLAGS:') ${CPPFLAGS}" echo Unfortunately this change leaks in optimisation flags into testsuite's conformtest.pl and breaks namespace conformance tests: FAIL: conform/ISO/setjmp.h/conform FAIL: conform/ISO/stdlib.h/conform FAIL: conform/ISO/stdlib.h/linknamespace ... The errors are in form of: Checking the namespace of "setjmp.h"... FAIL ------------------------------------------------------------------------ Namespace violation: "siglongjmp" ------------------------------------------------------------------------ That can be worked around as: --- a/conform/conformtest.pl +++ b/conform/conformtest.pl @@ -270,7 +270,7 @@ sub checknamespace { close (TESTFILE); undef %errors; - open (CONTENT, "$CC $CFLAGS_namespace -E $fnamebase.c -P -Wp,-dN | sed -e '/^# [1-9]/d' -e '/^[[:space:]]*\$/d' |"); + open (CONTENT, "$CC -O0 $CFLAGS_namespace -E $fnamebase.c -P -Wp,-dN | sed -e '/^# [1-9]/d' -e '/^[[:space:]]*\$/d' |"); loop: while (<CONTENT>) { chop; if (/^#define (.*)/) {
(In reply to Philipp Psurek from comment #4) Sergei is correct -- he's describing all the GNU IFUNC logic in glibc that supports multiple processors/ISA extensions in a single binary. all of that is permissible in Gentoo and needs no USE flag restriction.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ff56613857700dd0dfe2937539ae13fc3212eb4 commit 3ff56613857700dd0dfe2937539ae13fc3212eb4 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-06-26 07:54:33 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-06-26 09:48:14 +0000 sys-libs/glibc: pass user's CFLAGS over CC/XX, not CPPFLAGS Breakage example (before this change): # CFLAGS="-O2 -march=core2 -mno-sse4.2" emerge -v1 =glibc-2.27-r4 Here user's CFLAGS were able to override (this bug) glibc's CFLAGS additions like: sysdeps/i386/i686/multiarch/Makefile:CFLAGS-strspn-c.c += -msse4 'strspn' was built as 'gcc -msse4 -mno-sse4.2' and failed: smmintrin.h:631:1: error: inlining failed in call to always_inline ‘_mm_cmpistri’: target specific option mismatch This happens because we passed user's CFLAGS via CPPFLAGS: Makerules:COMPILE.c = $(CC) -c $(CFLAGS) $(CPPFLAGS) To avoid this kind of overrides this change injects user's CFLAGS into CC/CXX. Above example will use 'gcc -mno-sse4.2 -msse4' order. Reported-by: Philipp Psurek Bug: https://bugs.gentoo.org/657760 Closes: https://bugs.gentoo.org/659030 Package-Manager: Portage-2.3.40, Repoman-2.3.9 sys-libs/glibc/glibc-2.27-r5.ebuild | 1418 +++++++++++++++++++++++++++++++++++ sys-libs/glibc/glibc-9999.ebuild | 16 +- 2 files changed, 1426 insertions(+), 8 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4dc260608afee733d52135f9c87325d43593b57 commit d4dc260608afee733d52135f9c87325d43593b57 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-06-26 09:47:53 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-06-26 09:48:15 +0000 sys-libs/glibc: add USE=multiarch (enabled by default) Normally multiarch should be enabled (where available). But sometimes disabling multiarch is useful: - to workaround or validate bugs specific to selected runtime arch or IFUNC handling. - to get code that matches -march= CFLAGS setting Bug: https://bugs.gentoo.org/659030 Package-Manager: Portage-2.3.40, Repoman-2.3.9 sys-libs/glibc/glibc-2.27-r5.ebuild | 4 +++- sys-libs/glibc/glibc-9999.ebuild | 4 +++- sys-libs/glibc/metadata.xml | 1 + 3 files changed, 7 insertions(+), 2 deletions(-)
I am very impressed how fast this bug has been fixed. I like your solution and the implementation of “multiarch” very much. Thank you Sergei for fixing this bug, for your kind answers and for your time.
(In reply to Sergei Trofimovich from comment #6) > Unfortunately this change leaks in optimisation flags into testsuite's > conformtest.pl and breaks namespace conformance tests: > FAIL: conform/ISO/setjmp.h/conform > FAIL: conform/ISO/stdlib.h/conform > FAIL: conform/ISO/stdlib.h/linknamespace > ... Queued path for next glibc-2.27 patchset as: https://github.com/gentoo/glibc/commit/73d2a845b6de75ff401ade30545ce6f82d5c0fc2
