build(cuda): NVCC_ALLOW_UNSUPPORTED, so a host compiler newer than VS2022 is reachable

[Unknown-Findout]

CUDA 13.1's crt/host_config.h accepts only Visual Studio 2019 to 2022 and refuses anything newer. On a host with VS Build Tools 18 (MSVC 19.50) every nvcc target dies at the first #include:

host_config.h(164): fatal error C1189: #error: -- unsupported Microsoft Visual
Studio version! Only the versions between 2019 and 2022 (inclusive) are supported!

That is cuda-test, cuda-dll, all of it. nvcc ships -allow-unsupported-compiler for exactly this case, but there was no way to get one flag into the command line: NVCCFLAGS is the only handle, and replacing it wholesale discards $(CUDA_GENCODE), the -ccbin set above it, and the -Xcompiler=-W3 warning form Windows specifically needs.

That is the same argument the NVCC_STD comment already makes a few lines up, so this follows its shape rather than inventing a new one.

NVCC_ALLOW_UNSUPPORTED ?= 0
ifeq ($(NVCC_ALLOW_UNSUPPORTED),1)
NVCCFLAGS += -allow-unsupported-compiler
endif

Defaults to 0 on purpose. nvcc's own wording is "may cause compilation failure or incorrect run time execution", so running on an unsupported host compiler stays an explicit decision by the builder, and any result produced with it set should say so.

What it unblocks

make cuda-test had never completed on this machine. With the variable set, the whole recipe runs:

make cuda-test CUDA_ARCH=sm_86 NVCC_ALLOW_UNSUPPORTED=1
...
MAKE_EXIT=0

All seven binaries built and passed on real sm_86 silicon:

backend_cuda        q8/q4/q2/f32/e8 correctness ok on 1 device(s)
ragged_attention    ok
fp8_warp            decode sweep [shared-lut] 0 mismatches
                    decode sweep [hw-cvt]     0 mismatches
                    mutated entry (must bite) 1 mismatches   <- negative control fires
absorb_determinism  batch_differing=0/145  ragged_differing=0/29
fp8_cuda            oracle 50 trials x 3 experts, 0 mismatches
                    API: LUT gate + dense + sync group + async, 0 mismatches
weights_owned       8 fail cycles, 0 bytes cumulative
mxfp4               14/14 ok, incl. fmt=-1 and fmt=1073741824 refused as predicted

Worth noting the fp8 suite carries its own negative control - the deliberately mutated LUT entry reports 1 mismatches, so the zeros above come from a test that can fail.

Verification

Three tests in tests/test_cuda_test_makefile.py, the file that already owns this recipe's build contract.

The load-bearing one is test_allow_unsupported_compiler_preserves_the_other_flags. Appending must not do what a wholesale NVCCFLAGS override does, which is silently drop the gencode and lose -ftz=false - and -ftz is a correctness flag on this recipe rather than a tuning knob, per the comment beside it: the fmt=8 kernels are cross-tier parity instruments and a flushed scale*subnormal contribution diverges from the CPU reference. A build that lost it would still compile and still pass; only the parity numbers would quietly move.

Negative control run rather than assumed. Reverting the Makefile alone fails exactly one of the three:

FAIL  test_allow_unsupported_compiler_is_reachable
ok    test_allow_unsupported_compiler_is_off_by_default
ok    test_allow_unsupported_compiler_preserves_the_other_flags

That split is the correct one - off-by-default and flag-preservation are both already true without this change, so only the third assertion should move.

Full python suite: Ran 661 tests, OK, skipped=50.

One correction to my own first run

My first attempt reported the MXFP4 link failing with unresolved external symbol GOMP_parallel. That was my stale base, not a defect here: I had branched from a fork dev that was 115 commits behind and predated #1224. Rebased onto current dev, it links and passes. Recording it because the symptom is identical to the real bug #1224 fixed, and someone hitting it should check their base before filing.

Tested on Windows 11, RTX 3090 (sm_86), CUDA 13.1 V13.1.115, MSVC 19.50.35725, GNU Make 4.4.1, mingw-w64 gcc 16.2.0.