cuda-dll: make the Windows CUDA build work as shipped — MSVC host flags, CUDA_PATH defaults, POSIX shim in kernel test (#157, first hardware validation of #131's loader)

[lEWFkRAD]

Summary

First hardware validation of the #131 CUDA_DLL path (closes the build half of #157) — on RTX PRO 6000 Blackwell (sm_120), MSVC 14.44 + CUDA 13.2, MSYS2/UCRT64 host build. Result: the design works, but make cuda-dll was unbuildable as shipped by three Windows-specific issues, fixed here:

1. NVCCFLAGS passed GCC flags to MSVC. nvcc's host compiler on Windows is cl.exe, which hard-errors on -Xcompiler=-Wall,-Wextra (D8021 invalid numeric argument '/Wextra'). Windows now uses -Xcompiler=-W3 — dash form deliberately: MSYS make mangles /W3 into a filesystem path (C:/msys64/W3). POSIX branch byte-identical.
2. NVCC/CUDA_HOME defaults couldn't resolve on Windows. CUDA_HOME=/usr/local/cuda is meaningless there, and pointing at $(CUDA_PATH)/bin/nvcc fails the recipe's unquoted command -v because CUDA_PATH contains spaces. Windows now defaults CUDA_HOME from the installer's system-wide CUDA_PATH (for -L) and NVCC=nvcc from PATH — symmetric with the recipe's existing requirement that MSVC (cl) be on PATH via vcvars64.
3. tests/test_backend_cuda.cu used POSIX setenv/unsetenv — undefined under MSVC, so the kernel gate could never compile on Windows. Two-line _putenv_s shim.

Also corrects the stale "11 API symbols" comment — the header exports 15 and backend_loader.c resolves all 15.

Validation

• make cuda-dll CUDA_ARCH=sm_120 (stock flags) → coli_cuda.dll builds
• make glm CUDA_DLL=1 ARCH=native → [CUDA] device 0: NVIDIA RTX PRO 6000 Blackwell Workstation Edition, 102.6 GB VRAM, sm_120; tiny oracle TF 32/32 + greedy 20/20 with the GPU tier initialized
• Kernel gate on Windows: cuda backend: q8/q4/q2/f32 correctness ok on 1 device(s)
• Fallback contract: dll absent + COLI_CUDA=1 → clean "backend unavailable" message; no COLI_CUDA → pure-CPU run, no CUDA output, oracle-exact
• make -C c check still green (changes are confined to IS_WIN CUDA branches)

Compatibility

• The default CPU build remains dependency-free (no new link deps; dll is runtime-optional)
• No model files, generated binaries, or benchmark artifacts are included

🤖 Generated with Claude Code

[lEWFkRAD]

Pushed a second commit: running the actual VRAM expert tier on the 96 GB card surfaced a Windows heap-corruption crash in expert_host_release() — plain free() on the posix_memalign'd slab (= _aligned_malloc under compat.h) → 0xC0000374 on the first released expert. It's the same pattern the compat.h audit note fixed at the original expert_load site; this newer call site reintroduced it. One-line fix (compat_aligned_free), POSIX behavior unchanged.

Repro/validation on the RTX PRO 6000 (single GPU): CUDA_EXPERT_GB=80 CUDA_RELEASE_HOST=1 PIN=stats.txt PIN_GB=80 — deterministic crash at first expert release before, clean generation after. Two operational notes from the same session that may be worth a README line:

1. On a single-GPU host with more VRAM than RAM, CUDA_RELEASE_HOST=1 is effectively required — the default (keep host copies) tries to hold the VRAM tier twice and OOMs the host before the GPU (OOM slab + expert group launch: out of memory).
2. PIN_GB bounds the total placement pool including VRAM, not just the RAM share — PIN_GB=8 silently shrank an intended 80 GB VRAM tier to 8 GB. Fine once you know, surprising the first time.

VRAM-tier performance numbers for a real GLM-5.2 int4 run coming to #156's thread once the current battery finishes.

[juicyroots]

Independent confirmation of all three fixes on RTX 5090 (sm_120) + RTX 4090 (sm_89), Windows 11, MSVC 14.44 (VS2022 BuildTools) + CUDA 13.1, MinGW-w64 GCC 16.1 host:

• D8021: reproduced exactly as described — stock NVCCFLAGS -Xcompiler=-Wall,-Wextra fails with cl : Command line error D8021 : invalid numeric argument '/Wextra'; with host-neutral flags the DLL builds clean (445 KB, 15 exports).
• setenv/unsetenv: reproduced — test_backend_cuda.cu doesn't compile on MSVC without the shim; with it the full suite (incl. the WMMA int4 and group-stats cases) passes on both devices, single and dual init.
• aligned-free: this one is the important catch — we hit it independently while running CUDA_RELEASE_HOST=1 on Windows. expert_host_release freeing a posix_memalign (= _aligned_malloc) slab with plain free() corrupts the CRT heap the first time the disjoint placement releases host copies. With compat_aligned_free the full 744B model runs the dual-GPU expert tier stably (TF oracle 32/32, 0.72 tok/s with the tier + direct I/O from Windows: direct I/O (FILE_FLAG_NO_BUFFERING, 1.47x decode) + VirtualLock pin wiring + select_ctx device cache #162).

Hardware-validated on the full GLM-5.2 int4 checkpoint, not just the tiny oracle. Hope this helps it land — #162 builds on top of these fixes.

🤖 Generated with Claude Code

[JustVugg]

The glm.c merge wave just landed on dev and was promoted to main (make check 60/60, oracle TF 32/32 + greedy 20/20, MinGW cross-compile clean). Your PR pre-dated the crash-fix batch (#181/#183/#177) so it shows conflicts — one rebase onto current dev and it's mergeable; the wave is done, so nothing else will move under you (this was the point of batching: one rebase, not four). Sorry for the churn and thanks for the patience — ping me after the rebase and I'll merge promptly.