[Debian-med-packaging] Bug#983930: Bug#983930: kmc: ftbfs with -march=x86-64-v2

[Michael R. Crusoe]

Will building with x86-64-v2 and higher happen automatically in bullseye?

Or will it become policy to accept the introduction of -march=x86-64-v[234]
in the compiler flags?

If so, for SIMDe-using packages[0] we would then need to detect the
presence of -march=x86-64-v? in the *FLAGS and disable building multiple
versions of the binaries as we currently do manually in each packages
'debian/rules/

[0] https://wiki.debian.org/SIMDEverywhere#Packages_Status

On Sat, Aug 21, 2021 at 6:48 PM Étienne Mollier <emollier at emlwks999.eu>
wrote:

> Control: tag -1 confirmed
>
> Good day,
>
> having a closer look at kmc, there is simde set up, and it looks
> like enabling -march=x86-64-v2 leads through a buggy build path.
> Some parts of the source code are designed to build against some
> specific combinations of machine specific flags.  In the present
> case, if I inject -march=x86-64-v2, and some diagnostic output,
> then a mismatch appears between code targetting the specific cpu
> capability sse2, caused by availability of sse4.1 in build
> options:
>                                                   vvvv
>         In file included from kmer_counter/raduls_sse2.cpp:12:
>         kmer_counter/raduls_impl.h:734:2: warning: #warning
> "RADULS_RADIX_SORT_FUNNAME=RadixSortMSD_SSE41" [-Wcpp]
>
>                           ^^^^^
> thus, explaining the error reported by Matthias:
> > ./kmer_counter/kmc.h:1132: undefined reference to `void
> RadulsSort::RadixSortMSD_SSE2<CKmer<2u> >(CKmer<2u>*, CKmer<2u>*, unsigned
> long long, unsigned int, unsigned int, CMemoryPool*)'
> > collect2: error: ld returned 1 exit status
>
> To a larger extent, this is bound to fail with additional
> symptoms when using machine types x86-64-v3, as it appends
> various avx support, without mentionning various combinations
> thrown by -march=native.  I see two options to mitigate this:
>  1. either disable build of raduls_sse2.cpp, which is unneeded
>     in x86-64-v2 context, since it is overred by the sse4.1
>     implementation raduls_sse41.cpp any ways;
>  2. or cheat with the C preprocessor macro definitions, to get
>     back the missing function in its sse2 only context.
>
> Point 1 looks cleaner to me, but I only have been able to
> implement point 2 successfully so far, without causing baseline
> violations in normal builds, nor beating the purpose of
> optimisations, and with support for further flags combinations
> than just the baseline or -march=x86-64-v2.  Will push changes
> on Salsa this evening, most likely.
>
> Have a nice day,  :)
> --
> Étienne Mollier <emollier at emlwks999.eu>
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/6, please excuse my verbosity.
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20210822/c63537fd/attachment-0001.htm>