CI: pin the test ISA below AVX-512 - #55
Open
ax3l wants to merge 2 commits into
Open
Conversation
The Clang jobs that use libstdc++ started failing without a commit to
blame. libstdc++'s <experimental/simd> does not compile under Clang for
the AVX-512 mask ABIs:
simd_x86.h:4232: static assertion failed due to requirement
'is_same_v<long long, long>'
_MaskImplX86Mixin::_S_to_bits asserts is_same_v<_Tp,
__int_for_sizeof_t<_Tp>>, and under Clang __int_for_sizeof_t<long long>
is long, so simd<double, _VecBltnBtmsk<N>>::operator== never
instantiates. GCC compiles the same code.
The testsuite builds with -march=native, so what the job covers depends
on the CPU the runner happens to have. That changed under us: the fleet
moved to AVX-512 capable hardware, -march=native started selecting the
mask ABIs, and a job that had been green went red on an unchanged tree.
Pin those jobs to x86-64-v3, which every x86-64 runner supports, so the
Clang coverage stops depending on the runner. GCC keeps -march=native
and keeps testing AVX-512 where the runner offers it. clang-libcxx is
untouched: with libc++ there is no <experimental/simd>, so vir-simd uses
its own and never reaches this code.
The bug itself belongs to libstdc++, and this only stops it from
deciding whether CI is green.
Up to standards ✅🟢 Issues
|
ax3l
commented
Aug 26, 2026
Comment on lines
+56
to
+64
| # Pinned below AVX-512 on purpose. libstdc++'s <experimental/simd> does | ||
| # not compile under Clang for the AVX-512 mask ABIs: _S_to_bits asserts | ||
| # is_same_v<_Tp, __int_for_sizeof_t<_Tp>>, and for _Tp = long long that | ||
| # is false there, so simd<double, _VecBltnBtmsk<N>>::operator== fails to | ||
| # instantiate. The testsuite otherwise builds with -march=native, so | ||
| # this job started failing when the runner fleet moved to AVX-512 | ||
| # capable hardware, with nothing in this repository having changed. | ||
| # GCC compiles the same code, and keeps -march=native. | ||
| run: cd vir-simd && make check DRIVEROPTS=-vvf testflags=-march=x86-64-v3 |
Author
There was a problem hiding this comment.
This is really just a hot patch to get CI to green up. Not sure how to fix/work-around the underlying libstdc++ issue yet.
This was referenced Aug 26, 2026
The Clang jobs were not the only ones the runner fleet moved under.
simd_abi::max_fixed_size<int> is 32, so an AVX-512 simd<char>, which has
64 lanes, has no int ABI to match it. Two of the tests walk into that:
for_each.cc count_if wants deduced_simd<int, 64>, which has no type
transform.cc widening char to int asks for simd<int, fixed_size<64>>,
whose destructor libstdc++ deletes
transform fails the same way on GCC 11, 12 and 13, so this is not one
version's bug. And because the fleet is mixed, whether a job saw any of
it came down to which machine it landed on: GCC 11 passed one run and
failed the next on an unchanged tree.
Pin these jobs the same way, so what CI covers stops depending on the
runner. The AVX-512 coverage this gives up was never dependable -- where
a runner did offer it, these tests did not compile.
Fixing the algorithms is worthwhile separately; count_if is mattkretz#56. This is
only about CI reporting something reproducible.
ax3l
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Clang jobs that use libstdc++ went red without a commit to blame.
libstdc++'s
<experimental/simd>does not compile under Clang for the AVX-512 mask ABIs:_MaskImplX86Mixin::_S_to_bitsassertsis_same_v<_Tp, __int_for_sizeof_t<_Tp>>, and under Clang__int_for_sizeof_t<long long>islong, sosimd<double, _VecBltnBtmsk<N>>::operator==never instantiates:The testsuite builds with
-march=native, so what these jobs cover depends on the runner's CPU. That changed: the fleet moved to also include AVX-512 capable hardware (randomly assigned from Azure),-march=nativestarted selecting the mask ABIs, and the jobs went red on an unchanged tree.Pinning them to
x86-64-v3(supported by every x86-64 runner) stops Clang coverage depending on the runner. GCC compiles the same code fine and keeps-march=native, so AVX-512 stays covered there.clang-libcxxis untouched — with libc++ there is no<experimental/simd>, so vir-simd uses its own and never reaches this code.The bug is libstdc++'s; this only stops it deciding whether CI is green.
GCC's vector-compare on double yields long elements, Clang's yields long long. libstdc++'s
__int_for_sizeof_t<8>is int64_t = long on LP64.Reproduced locally with Clang 18 + libstdc++ 13: fails at
-march=skylake-avx512,sapphirerapids,znver4andx86-64-v4, passes atx86-64-v3. GCC 13/14 pass at-march=skylake-avx512.Update: the GCC jobs need the same pin, for a different reason.
simd_abi::max_fixed_size<int>is 32, so an AVX-512simd<char>(64 lanes) has no matchingintABI. Two tests walk into that:for_each.cccount_ifneedsdeduced_simd<int, 64>, which has notypetransform.ccchar→intasks forsimd<int, fixed_size<64>>, whose destructor libstdc++ deletestransform.ccfails identically on GCC 11, 12 and 13, so it is not one version's bug. Because the fleet is mixed, whether a job saw any of this came down to which machine it landed on — GCC 11 passed one run and failed the next on an unchanged tree.The AVX-512 coverage this gives up was never dependable: where a runner did offer it, these tests did not compile. Fixing the algorithms is worth doing separately (
count_ifis #56); this is only about CI reporting something reproducible.Validated on a fork: with the Clang pin, the Clang matrix goes green (ax3l#3).