Another <stdatomic.h> issue ?
-----
In Section 7.17.7.5 "The atomic_fetch and modify generic functions", the
C11/C18 Standards say:
1 The following operations perform arithmetic and bitwise
computations. All of these operations are applicable to an
object of any atomic integer type. ...
5 NOTE The operation of the atomic_fetch and modify generic functions
are nearly equivalent to the operation of the corresponding
op= compound assignment operators. The only differences are
that the compound assignment operators are not guaranteed to
operate atomically, and the value yielded by a compound
assignment operator is the updated value of the object,
whereas the value returned by the atomic_fetch and modify
generic functions is the previous value of the atomic object.
So given:
_Atomic(uint64_t*) foo ;
uint64_t* bar ;
bar = atomic_fetch_add(&foo, 1) ;
why do gcc 9.2/glibc 2.30 add 1 and not 8 to the address ?
I note that <stdatomic.h> maps atomic_fetch_add() to the built-in
__atomic_fetch_add(), which is indeed defined to work this way.
I grant that Section 7.17.7.5 is not a miracle of clarity (even by the
standards of the Standards). You could argue that atomic_fetch_xxx()
are simply not defined for atomic pointer types. But if so, *quietly*
accepting an undefined argument and then doing something odd with it,
strikes me as perverse.
FWIW: since the bitwise 'op=' are not defined for pointer types, it is
also a "surprise" that atomic_fetch_and() etc. accept pointer types.
It seems to me that gcc/glibc are broken, as are the Standards. How to
address that at this late stage looks tricky to me :-( Perhaps the
Standards could have a big dollop of Implementation Defined
retro-fitted; laid on thickly enough that might cover over the existing
mess ?
-----
I note that <stdatomic.h> is not mentioned in the GNU C manual for
v9.2.0 and also not mentioned in GNU C Library Reference Manual for
v2.31... So I'm guessing that 9 or so years after the C11 standard,
this remains such a mess that nobody can face trying to fix it ?
