Windows/MSVC build fails: '__cpuidex' identifier not found in glint/src/simd.hpp

[blixten]

Summary

Building on Windows with the MSVC toolchain fails to compile the glint library. glint/src/simd.hpp calls the MSVC intrinsic __cpuidex but does not include <intrin.h>, which declares it.

Environment

• OS: Windows 11
• Compiler: MSVC 19.39.33521.0 (cl.exe 14.39.33519, VS 2022 Build Tools)
• CMake 4.4, Ninja generator (via build-windows.bat)
• Commit: 705e355 (v0.8.24)

Steps to reproduce

build-windows.bat

Error

C:\...\CrispASR\glint\src\simd.hpp(28): error C3861: '__cpuidex': identifier not found

Fails identically for subband.cpp, mdct.cpp, encoder.cpp, etc. — any TU that includes simd.hpp.

Root cause

In detect_simd(), the _MSC_VER branch uses __cpuidex:

#elif defined(_MSC_VER)
    // MSVC: use __cpuid
    int cpuinfo[4];
    __cpuidex(cpuinfo, 7, 0);

__cpuidex is an MSVC intrinsic declared in <intrin.h>, which the header never includes. GCC/Clang builds take the __builtin_cpu_supports branch instead (no header needed), so this path was never exercised on Linux.

Fix

Add a guarded include near the top of glint/src/simd.hpp:

#include "glint/glint.h"

#if defined(_MSC_VER)
#include <intrin.h>  // __cpuidex
#endif

With this change the build completes and build\bin\crispasr.exe (v0.8.24) runs correctly. Happy to send a PR if preferred.

[CrispStrobe]

Fixed on main (dec2282) — thanks, the diagnosis was spot on, no PR needed.

Fixed upstream in CrispStrobe/glint@248970b first and re-synced, since tools/sync-glint.sh overwrites glint/ from upstream and an in-tree-only fix would have been reverted by the next sync.

Your <intrin.h> include is exactly right. Worth noting our windows-latest CI job does build crispasr-cli (which links glint) and still passes — some MSVC toolsets pull <intrin.h> in transitively, so whether this compiles has been down to luck. That is the argument for the explicit include rather than against it.

Two more bugs turned up in the same six lines while fixing it: the branch tested the AVX2 bit to gate a path that only uses _mm256_*_pd (AVX1 — so every Sandy/Ivy Bridge part silently fell back to SSE2 under MSVC while GCC ran it with AVX), and it never checked OSXSAVE/XGETBV before enabling AVX. Both corrected, plus a max-CPUID-leaf guard.