On 3/3/20 10:11 AM, Chris Hall wrote:
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 ?
In GCC this is due to the bug discussed in pr64843:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64843
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 ?
There are a number of bugs in atomics in C11. C17 fixed some, others
are either slated to be fixed in C2X or still being actively discussed.
The summary of C11 issues is here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm
-----
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 ?
A small number of people are working on improving the standard.
Anyone is welcome to help. If nothing else, it's an opportunity
to gain an appreciation for why change is slow.
Martin
