Re: Should atomic_xxx() functions reject not-_Atomic() arguments ?

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Fri, 6 Mar 2020 at 16:17, Chris Hall <gcc@gmch.uk> wrote:
>
> On 28/02/2020 15:27, Chris Hall wrote:
> > On 28/02/2020 01:01, Jim Wilson wrote:
> >> On Thu, Feb 27, 2020 at 7:20 AM Chris Hall <gcc@gmch.uk> wrote:
> >>> Now, the Standard also tells us that _Atomic(uint64_t) and uint64_t may
> >>> have different sizes, representations and alignment.  So I guess:
> >>>      bar = atomic_fetch_add(&bar, 1) ;
> >>> should be an error ?
>
> >> __atomic_fetch_add accepts any integer or pointer type.  So the fact
> >> that _Atomic(uint64_t) and uint64_t may be different types is not a
> >> problem, as long as they are still integer types.  This works like an
> >> overloaded function in C++.
> >>
> >> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins
>
> > Sure.  But the Standard atomic_fetch_add() takes an _Atomic(xxx)* (as
> > the first parameter), and for the reasons given, I understand that
> > uint64_t* is not compatible with _Atomic(uint64_t)*.

I don't think GCC is treating them as though they are compatible. It
just accepts a broader range of types than only  _Atomic ones, and
does the right thing for them all (apart from pointers where the
arithmetic is wrong).

> FWIW: clang gets this right, and where the Standard says a parameter
> must be an _Atomic(foo_t)* [for a standard atomic_xxx()], clang rejects
> foo_t* arguments.

It's not clear to me that C actually requires it to be rejected, or if
it's just undefined (in which case GCC's decision to accept it and do
the obvious thing is OK).