Re: `atomic_fetch_add` on pointer types?

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

The code
>
  #include <stdatomic.h>
  #include <stdio.h>
>
  int main()
  {
    int v[2], *_Atomic p = v;
    atomic_fetch_add(&p, 1);
    printf("%tu\n", (char *) p - (char *) v);
  }
>
GCC prints 1 (https://godbolt.org/z/55Pjcnd3Y), while Clang prints 4
(https://godbolt.org/z/e4x6z85fe). Obviously, Clang performed the
"proper" pointer arithmetic, while GCC ignored the pointer type.
>
Which one is correct here?

See also the thread in comp.std.c, where I wrote that I think you've
found an error in the standard.  (Probably just one newsgroup or the
other would have been more appropriate.)

IMHO neither is correct.  The description clearly restricts the
operations to atomic integer types.  The mention of "address types"
appears to be an error.

Perhaps the intent was to allow just _add and _sub on atomic pointer
types, but the standard doesn't express that intent.  If the intent
is to allow those operations on pointers, it seems clear that clang's
interpretation would be correct; pointer arithmetic counts elements,
not bytes.

Note that if you change atomic_fetch_add to _or, _and, or _xor, gcc
doesn't complain, which seems clearly incorrect.  clang correctly
complains "address argument to atomic operation must be a pointer
to atomic integer", but it quietly accepts _add and _sub.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */