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 <emoll...@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 <emoll...@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-packag...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging >
