Add missing _cuda_sm_x_y capability atoms (and fix the silent cuda_sm_8_9 → sm_80 CASE-table gap)

[nv-slang-bot]

Split from #12426, per @tdavidovicNV's request there (comment). This is deliverable [2].

Ask

Add the missing _cuda_sm_x_y capability atoms so Slang can name current CUDA architectures. The set reported by a recent NVRTC (12.6, cross-checked against nvcc --list-gpu-arch) but not representable today: 7.2, 7.5, 8.6, 8.7, 8.9, 10.0, 10.3, 11.0, 12.0, 12.1 (plus 5.2, 5.3, 6.1, 6.2 for completeness — see note). Today source/slang/slang-capabilities.capdef defines 11 _cuda_sm_* atoms.

⚠️ Fold in a pre-existing bug that lives in the same code path

There is a latent bug that must be fixed in the same change, because adding atoms without fixing it reproduces the bug at every new atom:

The atom→arch mapping is a second table, CASE(CUDASM, ...) in source/slang/slang-code-gen.cpp:627-636, which currently has only 9 rows against the 11 defined atoms — _cuda_sm_3_5 and _cuda_sm_8_9 have no row. Because _cuda_sm_8_9 : _cuda_sm_8_0, a request for _cuda_sm_8_9 silently falls back to the _cuda_sm_8_0 row:

slangc … -capability cuda_sm_8_9   →   .target sm_80   (want sm_89)

No diagnostic. Verified byte-identical to the cuda_sm_8_0 output; cuda_sm_9_0 correctly gives sm_90, so the mapping does discriminate — 8_9 genuinely resolves to 8_0. Every atom added in this issue needs its matching CASE row, or it silently degrades the same way.

Regression test to add (the coverage gap that let this hide)

Of the ~90 tests that pass -capability cuda_sm_*, none asserts anything about the emitted -arch / .target, which is why the 8_9 mis-map went unnoticed. Add a test that pins the emitted .target from a bare -capability on a shader with no cooperative-matrix / FP8 content.

That last constraint matters: the existing tests/cooperative-matrix/fp8-cuda.slang emits sm_89 via a different producer — slang-emit-cuda.cpp calls requireSMVersion(8,9) for FP8 elements, bypassing the CASE table entirely. Removing -capability from that test leaves the output byte-identical, so it does not guard this path. The regression test must exercise the CASE-table path, not the emit-tracker path.

One open design question (maintainers)

Capability atom enum values are assigned by declaration order (tools/slang-capability-generator/capability-generator-main.cpp), and atoms are serialized into .slang-module files as bit positions in that ordering (via UIntSetVal). So inserting new atoms mid-list changes the meaning of bytes in existing modules. Decision needed: append-only placement, or accept module invalidation on renumber? (The only unconditional cross-version guard today is a single flat kSupportedSerializationVersion; the build-tag digest is opt-in.)

Note on completeness

The originally-listed set omits 5.2 / 5.3 / 6.1 / 6.2, which that same NVRTC also reports; worth adding for the "complete vocabulary" goal. Newer entries (8.8, 10.0, 10.3, 11.0, 12.0, 12.1) can't be validated against NVRTC 12.6 locally — expected, they're newer architectures.

_{🤖 Filed by an automated Slang coworker at @tdavidovicNV's request on #12426 — a human maintainer should verify.}

[nv-slang-bot]

Triage outcome

• Status: Triaged → handed to slang-fixer, fix incoming. Classified feature-request (with a folded latent bug) / severity: medium / priority: P2 / component: capabilities + CUDA/PTX target-emit. Confirmed on master tip 28c755b0; no existing fix PR (not a duplicate). Parent Report capabilities supported by loaded downstream compilers and add missing CUDA architecture capabilities #12426 still open.
• Verdict (bug confirmed by code inspection): The CASE(CUDASM, …) table at source/slang/slang-code-gen.cpp:627-635 has 9 rows for the 11 _cuda_sm_* atoms in slang-capabilities.capdef:248-258 — _cuda_sm_3_5 and _cuda_sm_8_9 have no row. The switch's default: (:617-618) contributes nothing for an unlisted atom (no inheritance walk). Because the requested capability set is expanded to inherited ancestors and the downstream takes the max SemanticVersion, -capability cuda_sm_8_9 yields max(_cuda_sm_8_0→8.0, _cuda_sm_8_9→∅) = 8.0 → .target sm_80. The reporter's cuda_sm_9_0 → sm_90 control confirms this. One nuance: the _cuda_sm_8_9 / _cuda_sm_3_5 atoms and public aliases already exist — only their CASE rows are missing; the genuinely-new atoms to add are 7.2/7.5/8.6/8.7/10.0/10.3/11.0/12.0/12.1 (+5.2/5.3/6.1/6.2).
• Recommended fix (in the handoff memo): append-only new atoms (declared at the end with correct : <parent> inheritance edges so existing atom enum values — and therefore already-compiled .slang-module bit-positions — stay valid) + a CASE row for every atom (the 2 missing ones and all new ones) + regenerate docs/user-guide/a4-02-reference-capability-atoms.md + a regression test that pins the emitted .target from a bare -capability on a shader with no coop-matrix/FP8 content (the FP8 path re-adds SM 8.9 via requireSMVersion in slang-emit-cuda.cpp:342-348, bypassing this table, so it does not guard it). A minimal bug-only fallback (add just the 2 missing rows + test, defer the atoms) is available if the design question stalls.
• Next-action: slang-fixer implements; opens a draft PR (Closes #12839). Fix is pr: non-breaking under the append-only approach.
• Blocker (maintainer design decision — may need escalation before atoms land): placement of new atoms. Atom enum values are assigned by declaration order and serialized into .slang-module files as bit positions (UIntSetVal); kSupportedSerializationVersion (=1, flat) would not catch a silent renumber. Append-only avoids module invalidation but makes the inheritance chain non-linear for in-between archs (e.g. 8.6/8.7 become siblings off 8.0 rather than a strict 8.0→8.6→8.7→8.9 ladder); mid-list insertion keeps a clean chain but renumbers subsequent atoms and invalidates existing modules unless the serialization version is bumped. Please advise which is acceptable. (Also flagging a related latent risk for whoever implements: the downstream -arch selection at slang-nvrtc-compiler.cpp:~1313-1323 has a floor but no ceiling, so a very-high new atom could produce an -arch string NVRTC rejects.)

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[nv-slang-bot]

Fix in draft PR #12842 (held for maintainer review)

• Status: Fixed in draft PR Add missing CUDA SM capability atoms and fix the cuda_sm_8_9 → sm_80 CASE-table gap #12842 (pr: non-breaking, held pending human maintainer review — this issue is bot-filed, so it must not merge on automated sign-off).
• Link: Add missing CUDA SM capability atoms and fix the cuda_sm_8_9 → sm_80 CASE-table gap #12842
• What it does: Adds a CASE(CUDASM, …) row for every _cuda_sm_* atom (the 2 previously-missing _cuda_sm_3_5/_cuda_sm_8_9 and 13 new ones), fixing -capability cuda_sm_8_9 → .target sm_89 (was sm_80); adds 13 new CUDA SM atoms (5.2/5.3/6.1/6.2/7.2/7.5/8.6/8.7/10.0/10.3/11.0/12.0/12.1) + public aliases, appended so existing atom ordinals don't shift; regenerates both reference docs; adds a CASE-path regression test (bare -capability, no coop-matrix/FP8) — verified 3/3 (8.9→sm_89, 8.6→sm_86, 9.0→sm_90 control).
• Two decisions flagged for a maintainer in the PR body: (1) the label — appending Normal atoms shifts abstract/alias CapabilityName IDs, which are serialized in __target_switch cases with no version guard, so whether this is pr: non-breaking (precedent) or a .slang-module format break is your call; (2) the sibling-vs-ladder placement of in-between archs (e.g. 8.6/8.7 as siblings of 8.9 rather than a strict 8_0→8_6→8_7→8_9 ladder).
• Next-action: human maintainer review of PR Add missing CUDA SM capability atoms and fix the cuda_sm_8_9 → sm_80 CASE-table gap #12842 (and the two flagged decisions).

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}