Build C++/CUDA extensions with -std=c++20 (torch 2.14 ATen requires C++20)

[atalman]

Purpose

torch>=2.14 enforces a C++20 minimum in its ATen/torch headers (pytorch/pytorch#178150). Any translation unit that includes an ATen header while compiling under an older standard now trips:

#error C++20 or later compatible compiler is required to use ATen.

setup.py hardcodes -std=c++17 in both the cxx and nvcc flag lists. torch's cpp_extension only appends its own default -std=c++20 when the extension passes no -std= flag:

if not any(flag.startswith('-std=') for flag in cuda_flags):
    cuda_flags.append('-std=c++20')

so the pinned c++17 wins and the host compile of selective_scan.cpp (which pulls in ATen headers) fails against torch 2.14 nightly.

Change

Bump the pinned standard from c++17 to c++20 in both the CUDA and HIP branches of setup.py (4 occurrences). c++20 is already required by the toolchains this codebase targets (CUDA 12.x / Blackwell sm_121), so this is a no-op for stable torch builds and unblocks torch 2.14+.

Context

Currently worked around downstream in vLLM CI (vllm-project/vllm#49600) by patching this exact -std= flag at build time; this PR fixes it at the source so that workaround can be dropped.

Test plan

• pip install --no-build-isolation . against a torch 2.14 nightly build (previously failed at the ATen C++20 header guard, now compiles).
• Stable-torch builds are unaffected (compiling the c++17-era sources under c++20 is backward compatible).

---

This PR was drafted with the assistance of an AI agent and reviewed by the author.

[Chessing234]

c++20 for torch 2.14 makes sense. worth calling out in the readme that older nvcc toolchains might need a bump.

[janbernloehr]

Would it be preferable to remove the explicit -std= flags instead of changing them to C++20?
torch.utils.cpp_extension.BuildExtension already selects the minimum compatible standard when none is provided: older PyTorch versions add C++17, while current PyTorch adds C++20. Keeping an explicit flag overrides that version-aware behavior.
This also retains compatibility with older PyTorch/toolchain combinations.