bug: 18 AVX-512 tests in lance-linalg pass without asserting anything when the runner lacks the feature #8663

What's wrong

18 test functions in lance-linalg open with a runtime AVX-512 check and return early when it fails:

// rust/lance-linalg/src/distance/hamming.rs:1666
fn test_avx512_popcount() {
    if !is_x86_feature_detected!("avx512vpopcntdq") || !is_x86_feature_detected!("avx512f") {
        return;
    }
    // ... then 8 assert_eq! calls on hamming_batch_avx512's output
}

A bare return reports as ok. On a host without the feature the test passes having asserted nothing, and prints nothing to say so. There are 24 such gates across 18 functions. (A further 11 gates live in production dispatch code, where they belong.)

Six are named *_scalar_vs_avx512_parity. They are the only check that those kernels compute the right answer.

Why they may never have run anywhere

I can't tell you what CPU your jobs land on, and the claim doesn't need it: whether these 18 tests execute depends on a condition nobody guarantees, and when they don't execute they leave no trace.

GitHub documents no CPU-feature guarantee. The hosted-runners reference lists vCPU count, RAM, storage and architecture per label, with no CPU model, microarchitecture, or ISA feature anywhere. Asked directly:

• actions/runner#1069, requesting a way to select an AVX-512 runner, was closed with "GitHub Actions currently only runs on DS2V2 Azure VM which doesn't support AVX512, you will need to set up a self-hosted runner on the hardware you want to test for this."
• actions/runner-images#3389: "our agents are not guaranteed to have AVX-512, and only the way to enable the feature for you on permanent basis is to use self-hosted agents."

Both are from 2021, so read them as "no guarantee" rather than "no AVX-512". Recent reports look the same: vllm-project/vllm#36898 (March 2026) describes runners landing on Intel or AMD hosts non-deterministically, with Azure's AMD EPYC Zen 1 to 3 parts having no AVX-512 and an AVX-512 binary dying on SIGILL. Their wording: "AVX-512 availability is effectively random per job run."

The one job that runs lance-linalg tests in release mode, qemu-pre-haswell (.github/workflows/rust.yml:383), certainly doesn't reach them, since it is -cpu Nehalem. No qemu flag would fix that either. TCG has never implemented AVX-512 (qemu#844); I ran qemu-x86_64 10.0.11 with -cpu max and it still reports avx512f=0. That is also why the gap is invisible on an arm64 dev machine.

Suggested fixes

Two parts, and either one helps on its own.

Make the skip visible. A skipped parity test and a passing one currently look identical in the log. Printing the detected feature set once per file, or moving the gate into the test name so it shows up as filtered rather than passed, would at least let someone read a CI log and know which happened.

Find out whether the feature is there at all. One lscpu or grep flags /proc/cpuinfo step in an existing x86 job answers that permanently and costs nothing. If the fleet does have AVX-512, then only the visibility fix is needed. If it doesn't, 11 production kernels have no correctness coverage, which is worth knowing before someone adds the twelfth.

I'm not asking for dedicated AVX-512 CI hardware. Standing up self-hosted runners for one ISA extension is a lot of machinery for the benefit. Knowing which of the two situations we're in is the cheap part, and right now we don't.

Related

• Runtime SIMD dispatch can select an FMA kernel tier on a CPU without FMA #7732, runtime dispatch selecting an FMA kernel on a CPU without FMA: the same class of gap on the production side.
• lance-linalg build.rs: dist_table.c uses -march=native, silently dropping the AVX-512 kernel on non-AVX512 build hosts #7098, dist_table.c built with -march=native, silently dropping the AVX-512 kernel on a non-AVX-512 build host.