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

[Chris Hall]

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 perverse with 
it, strikes me as odd.

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 Library 
Reference Manual for version 2.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 ?