fix(kernel): GGUF JIT extension fails to build with gcc under C++17 - compile as C++20

[avlp12]

Problem

The GGUF JIT extension (freetoken/kernel/gguf.py) fails to build from a clean environment with recent libtorch + g++ 12/13/15 under the default -std=c++17:

• nvcc's host-compiler pass rewrites static_cast<typename decltype(impl_->list)::difference_type> in libtorch's ATen/core/List_inl.h into a form that drops the typename, which g++ rejects under C++17 (two hard errors; -fpermissive only downgrades the first).
• The file's existing comment assumes clang++ is the host compiler, but clang++ is not present on many systems (including ours), and torch's JIT helper happily picks g++.

Net effect: any deployment without clang++ cannot build the GGUF MoE kernels at all — ggml_moe_a8_vec etc. are unavailable, so GGUF-quant serving is broken on such hosts.

Fix

Compile the extension as -std=c++20: P0634 makes typename implicit in a static_cast type-id, so the nvcc-rewritten header parses cleanly. torch.utils.cpp_extension only appends its own -std=c++17 when no -std= flag is present, so passing it via extra_cuda_cflags is sufficient and does not fight torch's defaults.

No kernel source changes; the emitted device code is unchanged.

Verification

• Repro environment: WSL2 Ubuntu, torch 2.11.0+cu130, CUDA 13.3 nvcc, g++ 13 (also reproduced with g++ 12 and 15): build fails before, succeeds after.
• Behavior: kernels JIT-build and pass our full GGUF MoE test battery (dequant reference checks, ggml_moe_a8_vec numeric comparisons on q4_0/q4_K/iq2_xs/iq3_xxs) bit-identically to a clang-built binary of the same sources.
• In production use on our deployment (DeepSeek-V4-Flash, RTX 5090) since this change with no regressions.

🤖 Generated with Claude Code