groupshared-over-32k-without-attribute
Status: stub. The full-length analysis is queued for a v1.0.x patch release per ADR 0018, section 5, criterion #6. The companion rule page at docs/rules/groupshared-over-32k-without-attribute.md contains the canonical detection logic + GPU reasoning.
TL;DR
Per HLSL Specs proposal 0049 (Accepted), the SM 6.10 default groupshared cap is 32 KB; exceeding it requires the [GroupSharedLimit(N)] attribute. On SM 6.10 retail this compile-errors; on SM <= 6.9 the LDS allocation is silently truncated, producing out-of-bounds writes in groupshared. RDNA 3 and Turing/Ada have 64 KB / 100 KB / 128 KB caps respectively that the attribute opts the kernel into; without it the driver enforces the conservative ceiling.
What the rule fires on
Total groupshared allocation in a translation unit exceeding the SM 6.10 default of 32 KB without a [GroupSharedLimit(<bytes>)] attribute on the entry point.
See the What it detects section of the rule page for the full pattern definition.
Why it matters
The full GPU-mechanism analysis lives in the Why it matters on a GPU section of the companion rule page.
Examples
The bad / good code snippets are kept canonical on the rule page; see groupshared-over-32k-without-attribute.md -> Examples.
See also
- Rule page -- canonical reference + change log.
- sm6_10 overview -- broader context.
- ADR 0018 -- v1.0 readiness plan.
This is a v1.0-ship stub. Full analysis pending; track issue link TBD.