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

[Étienne Mollier]

Hi Michael, Hi Matthias,

Michael R. Crusoe, on 2021-08-22:
> 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?

I don't know for sure about the exact rationale behind the newer
baselines introduced, but I know some users may rebuild some
packages with -march=native, or other custom machine specific
flags, to boost performance of their equipment with newer cpus.
I don't expect this sort of configuration to be release critical
any time soon, but I think it is nice to have for these users.

Having a build that goes through with mixed machine specific
options seems consistent to me with the minor severity of the
present bug.  Matthias, is my thinking consistent with the
rationale behind introduction of tests with -march=x86-64-v?

> 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

Agreed, I would tend to extend such check to any -m* flag from
maintainer build environment in the filtering, to discriminate
regular buildd distribution builds from user's custom rebuild.

kmc is probably not the best example of package using simde,
since d/rules only builds a subsection of the packages for
compatibility once (I believe there is some runtime detection),
and not the entire program several times per architecture.  This
might also explain why I've seen this sort of bug only against
kmc so far; but maybe I missed other occurrences in the bug
tracker.

Have a nice day,  :)
Étienne.

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

-- 
Étienne Mollier <emollier at emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20210822/9e085dcf/attachment.sig>