Control: tags -1 ftbfs confirmed

Hi Jochen,

> /usr/lib/gcc/x86_64-linux-gnu/14/include/tmmintrin.h:185:1:
>       error: inlining failed in call to ‘always_inline’ ‘_mm_alignr_epi8’:
>       target specific option mismatch
>   185 | _mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N)
>       | ^~~~~~~~~~~~~~~
> ../../src/compress.c:781:17: note: called from here
>   781 |       current = _mm_alignr_epi8(old_prev,prev,4);

Thanks for your report, for the context, gmap is being ported to
SIMDe[1] upstream, so as to facilitate portability.  Fragile or
missing implementation details are compensated in the Debian
patch simd_fixes, but evidently some configurations have fallen
through the net.  I confirm reproducing the failure to build
from source in a virtual machine emulating Intel Sandy Bridge.

[1]: https://wiki.debian.org/SIMDEverywhere

> This looks like a baseline violation to me.

Thankfully, there should not be a baseline violation here.  What
happens upon execution is, that gmap will dynamically select the
appropriate binary in the set:

  * gmap.avx2
  * gmap.avx512
  * gmap.nosimd
  * gmap.sse2
  * gmap.sse41
  * gmap.sse42
  * gmap.ssse3

It is possible to ascertain that the selection is correct, as
the program will show which extensions have been compiled in,
e.g. on Intel Sandy Bridge:

        $ gmap --version | grep SIMD
        GMAP version 2024-11-20 called with args: gmap.sse42 --version
        SIMD functions compiled: SSE2 SSE3 SSE4_1 SSE4_2

By comparison, when forcing avx512 support:

        $ gmap.avx512 --version | grep SIMD
        GMAP version 2024-11-20 called with args: gmap.avx512 --version
        SIMD functions compiled: SSE2 SSE3 SSE4_1 SSE4_2 AVX2 AVX512

Besides the autopkgtest runs without raising illegal instruction
errors, and I believe the affected compression function should
be covered by the test (although I'm not 100% sure of that).
Therefore, as you might have already suspected by not setting
the severity to serious, the only matter for concern here is
really the build failure on older processor.  Hopefully this is
going to be resolved by newer upstream version 2025-04-11 or
later.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emoll...@debian.org>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-    on air: LCD Soundsystem - Someone Great

Attachment: signature.asc
Description: PGP signature

Reply via email to