Bug 853646 – 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

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Luke-Jr 2022-06-22 02:26:02 UTC]

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.

[Comment 1 Luke-Jr 2022-06-22 02:28:14 UTC]

Created attachment 786620 [details]
emerge --info

[Comment 2 Larry the Git Cow 2022-06-26 08:38:43 UTC]

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 <[e-mail]>
AuthorDate: 2022-06-26 08:38:05 +0000
Commit:     Stephan Hartmann <[e-mail]>
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 <[e-mail]>

 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(-)

[Comment 3 Roman Žilka 2022-07-01 11:44:58 UTC]

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);
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Comment 4 Roman Žilka 2022-07-01 11:47:10 UTC]

Created attachment 789161 [details]
[rz] emerge --info

[Comment 5 Roman Žilka 2022-07-01 11:48:33 UTC]

Created attachment 789164 [details]
[rz] build log - default setup

[Comment 6 Roman Žilka 2022-07-01 11:49:27 UTC]

Created attachment 789167 [details]
[rz] build log - filter flags without -mno-xop

[Comment 7 Roman Žilka 2022-07-01 11:50:08 UTC]

Created attachment 789170 [details]
[rz] build log - removed xnnpack from keeplibs

[Comment 8 Roman Žilka 2022-07-01 12:11:49 UTC]

Cc: Alfredo Tupone to kindly help with this xnnpack-related issue.

[Comment 9 Stephan Hartmann (RETIRED) 2022-07-01 12:30:05 UTC]

Can you try without -mno-sse4a?

[Comment 10 Luke-Jr 2022-07-01 14:30:42 UTC]

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.

[Comment 11 Roman Žilka 2022-07-01 19:31:07 UTC]

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).

[Comment 12 Larry the Git Cow 2022-08-20 08:20:29 UTC]

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 <[e-mail]>
AuthorDate: 2022-08-20 08:19:57 +0000
Commit:     Stephan Hartmann <[e-mail]>
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 <[e-mail]>

 www-client/chromium/chromium-104.0.5112.101.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Comment 13 Ionen Wolkens 2023-08-30 01:49:32 UTC]

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).

[Comment 14 Ionen Wolkens 2023-09-02 15:16:15 UTC]

(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.