[libcxx-commits] [clang] [libcxx] [Clang][POC] Allow atomic operations on _BitInt(N) (PR #204815)

[Xavier Roche via libcxx-commits]

xroche wrote:

> I do think we should also test something in C23 and C2y modes.
> 
> BTW, is there anything disallowing `_Atomic _BitInt(N)` in C23 (or latest C2y draft)?
> 
> WG14 [N2763](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) said that
> 
> > Removed the _BitwidthOf, file IO, literal suffixes, and atomic functionality and added a Future Directions section to the prose
> 
> But it seems that C23 still requires support for `_Atomic _BitInt(N)`...

It sees that this is indeed the other way: C23 requires `_Atomic _BitInt(N)` rather than merely allowing it.

- The atomic type specifier's constraint names every excluded type:

> The type name in an atomic type specifier shall not refer to an array type, a function type, an atomic type, or a qualified type.

`_BitInt(N)` is none of those, so `_Atomic(_BitInt(N))` is well-formed at every width. The library side matches: the `<stdatomic.h>` generic functions are defined for any atomic type, and Gustedt's C23-library notes list `_BitInt(N)` support in the type-generic interfaces as a mandatory addition (and a hard one for `_Generic`-based implementations).

What N2763 deferred to Future Directions was the dedicated atomic additions for `_BitInt`, the named `atomic_*` typedefs and lock-free macros. The `_Atomic` qualifier and the generic operations stayed required. gcc-14 already accepts the construct in C23 mode AFAICS, so the current Clang rejection is a conformance gap, not a missing extension to me :shrug:

Ps: I added coverage for both modes: a Sema acceptance test for the `_Atomic(_BitInt(N))` specifier and the `__c11_atomic_*` builtins in C23 and C2y, plus a `-std=c2y` run of the codegen test

https://github.com/llvm/llvm-project/pull/204815