| Summary: | www-client/chromium-103.0.5060.53: ../../third_party/xnnpack/src/src/qu8-vadd/gen/minmax-xop-mul32-ld32-x8.c:46:24: error: always_inline function '_mm_macc_epi32' requires target feature 'xop', but would be inlined into function 'xnn_qu8_vadd_minmax_ukern | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Luke-Jr <luke-jr+gentoobugs> |
| Component: | Current packages | Assignee: | Chromium Project <chromium> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ionen, roman.zilka, tupone |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build log
emerge --info [rz] emerge --info [rz] build log - default setup [rz] build log - filter flags without -mno-xop [rz] build log - removed xnnpack from keeplibs |
||
Created attachment 786620 [details]
emerge --info
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=96d8035a25813cf58e6f6828dc174318ba130267 commit 96d8035a25813cf58e6f6828dc174318ba130267 Author: Stephan Hartmann <sultan@gentoo.org> AuthorDate: 2022-06-26 08:38:05 +0000 Commit: Stephan Hartmann <sultan@gentoo.org> CommitDate: 2022-06-26 08:38:39 +0000 www-client/chromium: filter out -mno-xop Closes: https://bugs.gentoo.org/853646 Signed-off-by: Stephan Hartmann <sultan@gentoo.org> www-client/chromium/chromium-103.0.5060.53.ebuild | 4 ++-- www-client/chromium/chromium-104.0.5112.12.ebuild | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) I'm running into this error with (build log 1) or without (build log 2) "-mno-xop" in filter-flags. Using gcc, not clang. My CPU doesn't have XOP.
Emerging sci-libs/XNNPACK and removing "third_party/xnnpack" from keeplibs in the ebuild doesn't help either - the build complains it's missing xnnpack (build log 3).
The exact message from gcc is:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/x86intrin.h:38,
from ../../third_party/xnnpack/src/src/qu8-vadd/gen/minmax-xop-mul32-ld32-x8.c:13:
../../third_party/xnnpack/src/src/qu8-vadd/gen/minmax-xop-mul32-ld32-x8.c: In function ‘xnn_qu8_vadd_minmax_ukernel__xop_mul32_ld32_x8’:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/xopintrin.h:71:1: error: inlining failed in call to ‘always_inline’ ‘_mm_macc_epi32’: target specific option mismatch
71 | _mm_macc_epi32(__m128i __A, __m128i __B, __m128i __C)
| ^~~~~~~~~~~~~~
../../third_party/xnnpack/src/src/qu8-vadd/gen/minmax-xop-mul32-ld32-x8.c:50:16: note: called from here
50 | vacc4567 = _mm_macc_epi32(vb4567, vb_multiplier, vacc4567);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Created attachment 789161 [details]
[rz] emerge --info
Created attachment 789164 [details]
[rz] build log - default setup
Created attachment 789167 [details]
[rz] build log - filter flags without -mno-xop
Created attachment 789170 [details]
[rz] build log - removed xnnpack from keeplibs
Cc: Alfredo Tupone to kindly help with this xnnpack-related issue. Can you try without -mno-sse4a? I had to strip: -mno-xop -mno-sse4a -mno-fma4 And also various -mno-avx512* flags (but I didn't bisect which specific ones were the problem) In my case, this was safe, but in other cases, users might actually needs these flags (for example, building for a newer -march but needing binary packages compatible with older CPUs). Upstream should really fix this by checking that the intrinsics are available (with the user CFLAGS passed). Or at the very least, override the user CFLAGS for specific features when they are building files that will only be conditionally used at runtime. That did it, thanks! I needed to remove mno-sse4a and mno-avx512*. mno-xop was already removed by the ebuild (I didn't check whether leaving it in it would've been an issue). The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9ae7b094d523860ef685b03b4f0e2c19b8653080 commit 9ae7b094d523860ef685b03b4f0e2c19b8653080 Author: Stephan Hartmann <sultan@gentoo.org> AuthorDate: 2022-08-20 08:19:57 +0000 Commit: Stephan Hartmann <sultan@gentoo.org> CommitDate: 2022-08-20 08:19:57 +0000 www-client/chromium: filter out -mno-sse4a Closes: https://bugs.gentoo.org/853646 Signed-off-by: Stephan Hartmann <sultan@gentoo.org> www-client/chromium/chromium-104.0.5112.101.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) An alternate "easy" option could(?) be to just disable xnnpack (potentially conditionally w/ a warning depending on offending -mno-* if not always). aka build_tflite_with_xnnpack=false (default false if non-amd64) Not that I'm requesting anything, just mentioning given I was looking at respecting flags in qtwebengine and wondered if I needed to worry about this, but turned out Qt just always disables tflite (only xnnpack consumer, or at least it is in that older chromium version Qt uses). (In reply to Ionen Wolkens from comment #13) > I was looking at respecting flags in qtwebengine and wondered > if I needed to worry about this Well, turns out I do. It still has issues with this but in other components like webrtc with -mno-avx2. Not ideal, but ftr planning to swap flags positions to help this in qtwebengine. aka: -mavx2(chromium) -mno-avx2(user) becomes: -mno-avx2 -mavx2 And then things build just fine (or at least when nothing relies on e.g. -mno-avx2 -march=haswell to enable avx2). This is only used for bits meant for runtime detection, and aren't executed without support. Just need to make sure (at least) no -O or -g slip in after user's flags. It'd be nice if chromium had a separate variable to add simd flags that would go after even extra_c(xx)flags -- or at least have a switch to control building each of these. Albeit that all requires changing a fair amount of files. |
Created attachment 786617 [details] build log ../../third_party/xnnpack/src/src/qu8-vadd/gen/minmax-xop-mul32-ld32-x8.c:46:24: error: always_inline function '_mm_macc_epi32' requires target feature 'xop', but would be inlined into function 'xnn_qu8_vadd_minmax_ukernel__xop_mul32_ld32_x8' that is compiled without support for 'xop' No doubt because I use -mno-xop, since my CPU doesn't support 'xop'. Curiously, sci-libs/XNNPACK builds fine.