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

Jonathan Wakely jwakely.gcc@gmail.com
Sat Mar 7 19:27:35 GMT 2020


On Sat, 7 Mar 2020 at 11:00, Andrew Haley <aph@redhat.com> wrote:
>
> On 3/6/20 5:45 PM, Jonathan Wakely wrote:
> > On Fri, 6 Mar 2020 at 16:17, Chris Hall <gcc@gmch.uk> wrote:
> >
> >> 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).
>
> Except in pedantic mode.

If the standard doesn't actually forbid it (which I don't think it
does) then it's up to the implementation if and when it diagnoses it.
Doing so for -pedantic might be reasonable though.

> I remember there was a move to actually permit
> this in C++:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4013.html
>
> This seems obviously right to me...

Yeah. The feature is in C++20, via the std::atomic_ref<T> template.
You wrap an ordinary non-atomic variable in an atomic_ref and can
perform atomic operations on it.

For this to work, the implementation has to be able to accept
non-atomic variables in its __atomic_xxx functions (though not
necessarily in the public atomic_xxx ones).



More information about the Gcc-help mailing list