Hi, On one of my AMD64 machine, net-libs/nodejs-18.7.0:0/18::gentoo fails to build. The target doesn't have AVX2 support, CFLAGS contains -mnoavx2 but I see -DHAVE_AVX2=1 in the compile line. Thus GCC complains: [...] x86_64-pc-linux-gnu-gcc -o /var/tmp/portage-notmpfs/portage/net-libs/nodejs-18.7.0/work/node-v18.7.0/out/Release/obj.target/base64_avx2/deps/base64/base64/lib/arch/avx2/codec.o ../deps/base64/base64/lib/arch/avx2/codec.c '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1' '-DNODE_OPENSSL_CONF_NAME=nodejs_conf' '-DNODE_OPENSSL_CERT_STORE' '-D__STDC_FORMAT_MACROS' '-DBASE64_STATIC_DEFINE' '-DHAVE_AVX2=1' -I../deps/base64/base64/in clude -I../deps/base64/base64/lib -pthread -Wall -Wextra -Wno-unused-parameter -m64 -mavx2 -fno-omit-frame-pointer -O2 -pipe -fomit-frame-pointer -march=ivybridge -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mno-avx2 -mno-sse4a -mno-fma4 -mno-xop -mno-fma -mno-avx512f -mno-bmi -mno-bmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124 fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -mno-adx -mno-abm -mno-cldemote -mno-clflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mno-lzcnt -mno-movbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mno-prfchw -mno-ptwrite -mno-rdpid -mrdrnd -mno-rdseed -mno-rtm -mno-serialize - mno-sgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mno-xsavec -mxsaveopt -mno-xsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=ivybridge -c In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/include/immintrin.h:47, from ../deps/base64/base64/lib/arch/avx2/codec.c:12: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/include/avx2intrin.h: In function ‘dec_reshuffle’: /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/include/avx2intrin.h:1044:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_permutevar8x32_epi32’: target specific option mismatch 1044 | _mm256_permutevar8x32_epi32 (__m256i __X, __m256i __Y) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../deps/base64/base64/lib/arch/avx2/codec.c:14: ../deps/base64/base64/lib/arch/avx2/dec_reshuffle.c:33:16: note: called from here 33 | return _mm256_permutevar8x32_epi32(out, _mm256_setr_epi32(0, 1, 2, 4, 5, 6, -1, -1)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/include/avx2intrin.h:588:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_shuffle_epi8’: target specific option mismatch 588 | _mm256_shuffle_epi8 (__m256i __X, __m256i __Y) | ^~~~~~~~~~~~~~~~~~~ ../deps/base64/base64/lib/arch/avx2/dec_reshuffle.c:24:15: note: called from here 24 | out = _mm256_shuffle_epi8(out, _mm256_setr_epi8( | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 25 | 2, 1, 0, 6, 5, 4, 10, 9, 8, 14, 13, 12, -1, -1, -1, -1, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26 | 2, 1, 0, 6, 5, 4, 10, 9, 8, 14, 13, 12, -1, -1, -1, -1)); [...] Reproducible: Always
Created attachment 797521 [details] build log
Created attachment 797524 [details] emerge --info
Putting "-mno-xxx" in your CFLAGS is generally a bad idea. Instead, just pick an appropriate value for -march. I would guess that nodejs contains AVX2 code that is conditionally invoked at runtime depending on the capabilities CPU it is running on. It needs to enable the appropriate intrinsic functions this one source file via -mavx2, but your CFLAGS are forcing that to be disabled via -mno-avx2.
if this is the case that AVX2 code is conditionally loaded at runtime, couldn't we add somme CFLAGS filtering in the ebuild?
(In reply to Xavier Miller from comment #4) Yes, but such filter would be unnecessary if users would stop adding -mno-avx2 to there CFLAGS. It really does nothing useful and just causes random build failures like this one.
I agree with Mike. There is no way we can filter out all incompatible CFLAGS, so the best thing for users to do is stick with the flags we consider safe. Please see the following page for more information on this subject. https://wiki.gentoo.org/wiki/Safe_CFLAGS Thanks, William
BTW the wiki page shows examples with "-mo-avx" and the like flags. I followed the page, and my CFLAGS are the results of gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 By those -mnoXXX flags I am sure the binpkgs I build are compatible with the old CPUs. If no fix is proposed, I will simplify the CFLAGS through package.env
Hmm, I didn't realize Intel made ivybridge chips that lack AVX and other extensions. How confusing. We could add "strip-flags -mno-avx2" to the ebuild, but then you would risk having the compiler emit instructions in other objects that will not run on all CPUs you want to support. To fix this, upstream would need to alter their build system to put -mavx2 after the user's flags for the files where runtime CPU detection is implemented.
@Mike Gilbert Having the same issue, I was pointed towards this bug. The status reads RESOLVED UPSTREAM, however, is this wishful thinking or has it indeed been fixed upstream? I'm not sure how to work around this for now, but waiting for a fix maybe in the newly released 19.0.0 would make this obsolete in the first place. Ref: https://forums.gentoo.org/viewtopic-p-8754677.html
(In reply to Sven Schwyn (svoop) from comment #9) > @Mike Gilbert > > Having the same issue, I was pointed towards this bug. The status reads > RESOLVED UPSTREAM, however, is this wishful thinking or has it indeed been > fixed upstream? > RESOLVED UPSTREAM doesn't actually mean the problem has been fixed upstream. It means we can't fix the problem in Gentoo, and the problem should be addressed by the upstream developers. > I'm not sure how to work around this for now, but waiting for a fix maybe in > the newly released 19.0.0 would make this obsolete in the first place. You can work around the problem by selecting an -march setting via CFLAGS that does not enable the avx2 instructions.
A correction here: The -march=ivybridge option enables AVX, but not AVX2. Having -mno-avx2 in your CFLAGS seems pointless.
@Mike Gilbert Thanks for your reply! Turns out, the root of my problem was a rather stupid mistake in the COMMON_FLAGS, but good to know how to interpret "RESOLVED UPSTREAM" in the future.
*** Bug 906604 has been marked as a duplicate of this bug. ***
