https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114469
--- Comment #1 from Joseph S. Myers <jsm28 at gcc dot gnu.org> --- I'd expect _Atomic _BitInt(5) to follow the same ABI (regarding upper bits being defined or not) as plain _BitInt(5), and any simplification needs to deal with that. (In principle for atomics with _BitInt with padding bits there are the same concerns as for any types with padding bits - any compare-and-exchange loop needs to succeed eventually when the underlying memory isn't being modified, rather than failing in comparison of padding bits that might not have been consistently loaded / preserved. My guess is this is unlikely to be a concern in practice for _BitInt the way it is e.g. for x86 long double where the padding bits only exist in memory and not in registers.)
