https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61625
Bug ID: 61625
Summary: _Atomic should create a new type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nfxjfg at gmail dot com
It seems currently, the C11 _Atomic attribute is treated as something like a
storage class (or whatever else as what the compiler treats this internally),
instead of constructing a new type that is separate from non-atomic types.
The C11 standard doesn't seem to require making _Atomic a separate type, but it
does seem to allow for it. For example, the ATOMIC_VAR_INIT standard macro
would not be required if _Atomic is always meant to be assignable from
non-atomic values.
I'm arguing that it would be better to treat _Atomic types as separate, as it
prevents assigning values in a non-atomic way (and also disallowed by C11,
AFAIK). It would help developers writing correct code, and might even give an
advantage to use gcc over other compilers for development.
Interestingly, FreeBSD's stdatomic.h emulation [1] tries something similar: it
makes all atomic types wrapped in structs, which makes them incompatible with
assignment from non-atomic variables. But of course the FreeBSD "trick" is not
strictly correct, since _Atomic types needs to be equal to other _Atomic types
with the same structure.
[1] https://github.com/freebsd/freebsd-head/blob/master/include/stdatomic.h
