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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)*.

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.

Chris



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux