On Fri, 6 Mar 2020 at 16:17, Chris Hall <gcc@xxxxxxx> 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@xxxxxxx> 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).
