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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
