Are atomic_fetch_xxx() functions broken for atomic-pointer types ?

Martin Sebor
Tue Mar 3 17:35:00 GMT 2020

On 3/3/20 10:11 AM, Chris Hall wrote:
> Another <stdatomic.h> issue ?
> -----
> In Section "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:

> 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 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:

> -----
> 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.


More information about the Gcc-help mailing list