ci: cover i386 and ClangCL for the AVX2-dispatch guard; drop dead _M_X64

[filipecosta90]

Follow-up to #142 (ClangCL) and #143 (i386), which both edited the AVX2 runtime-dispatch guard in src/hdr_histogram.c but were validated manually rather than in CI.

Why

The CI matrix excludes 32-bit Linux and never selects the ClangCL toolset, so neither configuration the guard specifically handles was exercised. A future refactor of the guard could silently reintroduce either break.

What

Two regression jobs, in both of which HDR_HAS_AVX2_DISPATCH must be compiled out:

• build-linux-i386 — 32-bit GCC (-m32, gcc-multilib), HDR_LOG_REQUIRED=DISABLED so no 32-bit zlib is needed. The core suites still run hdr_value_at_percentile (the dispatched path). Guards against the Don't attempt AVX2 on i386 #143 break (_mm_extract_epi64 is unavailable in 32-bit codegen).
• build-windows-clangcl — the ClangCL VS toolset (-T ClangCL) on x64. Guards against the Fix ClangCL build on Windows #142 break (clang-cl defines __clang__+_MSC_VER and previously failed to link __cpu_model).

Also simplifies the guard: _M_X64 is a dead term once _MSC_VER is excluded (only the MSVC family defines _M_X64, and clang-cl uses _M_X64 rather than __x86_64__), so it now gates on __x86_64__ alone, with a comment documenting why 32-bit / MSVC-ABI / ICC are excluded.

No functional change on the platforms that ship the AVX2 path (64-bit GCC/Clang on Linux/macOS): the fast path stays enabled there.

🤖 Generated with Claude Code

[github-actions]

🤖 Automated first-pass review — a human maintainer's review is still required before merge.

The guard simplification checks out: _M_X64 really is dead once !defined(_MSC_VER) is in the condition, since every compiler that defines _M_X64 (cl, clang-cl, ICC on Windows) also defines _MSC_VER, and MinGW-w64 x86_64 still comes in via __x86_64__ as before — no platform changes branch. Nothing here touches struct hdr_histogram's layout or an existing public signature (count_leading_zeros_64 is static, hdr_atomic.h is a private header, and the recorder change is call-site casts only), so no SOVERSION move is implied. The unsigned long out-param is right on every branch that guard selects — Windows is LLP64, so it's 32-bit there and the 63 - leading_zero result is unchanged. The (void**) casts match the idiom already in test/hdr_atomic_test.c:37, all three call sites in the tree are covered, and they also clear the incompatible-pointer warnings the existing MSVC matrix jobs have presumably been emitting quietly (no -Werror here, so nobody would have noticed).

Two things I'd tighten in the CI half:

• The ClangCL job's comment says it "fails if the exclusion regresses", but unlike the i386 job it has no explicit HDR_HAS_AVX2_DISPATCH assert — its only regression signal is the link failing on __cpu_model. That is what broke in Fix ClangCL build on Windows #142, but it's indirect: if clang's builtins are linkable in some future image, the job goes green with the dispatch wrongly enabled. Worth the same negative macro assert you gave i386, for symmetry.
• The positive assert is if: matrix.os == 'linux' only, yet macOS x64 also ships the AVX2 path. Cheap to extend, and it's the other half of the guard this PR is pinning down.

One thing I can't verify from the diff: whether the i386 build actually links, specifically whether 64-bit __atomic_* under -m32 needs -latomic for hdr_histogram_atomic_test / hdr_histogram_atomic_concurrency_test (the latter is if(UNIX), so it does get built here). The job's own run answers that, and that's the right place for it.