[cfe-dev] [libcxx] atomic header and low-level intrinsics

[David Chisnall]

Hi Al,


On 25 Mar 2012, at 22:42, Al Grant wrote:

> These are similar to but incompatible with the new GCC atomic intrinsics:
> 
>  http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> 
> which include
> 
>  type __atomic_load_n (type *ptr, int memmodel);
>  void __atomic_load (type *ptr, type *ret, int memmodel);
> 
> Is there any reason not to move libcxx <atomic> to use these GCC intrinsics,
> and have clang implement them?

Clang already implements the intrinsics.  I have a patch adding the remaining codegen parts that should be going in this week.  With this applied, most of the libc++ atomics tests now pass for me.

> Also, I noticed a couple of minor issues with libcxx <atomic> and its tests:
> 
> The pointer operations e.g.
> 
>    _Tp* fetch_add(ptrdiff_t __op, memory_order __m = memory_order_seq_cst)
>        {return __atomic_fetch_add(&this->__a_, __op, __m);}
> 
> don't seem to match the defined intrinsics:
> 
>  void* __atomic_fetch_add(void** atomic_obj, ptrdiff_t operand, int mem_ord);
> 
> Either the low-level intrinsics need to be polymorphic, or <atomic> needs
> some casts and also needs to scale the ptrdiff_t value.

The intrinsics are polymorphic.

> Finally, various libcxx atomic tests attempt to instantiate atomic<> on a
> struct A which is not trivially-copyable and hence not valid (29.5#1 in N3290).
> Is libcxx intending its <atomic> to support such types on all platforms?

This is a bug in the test.  Howard said he'd fix it a couple of months ago when I raised this issue, but as I've only just got around to finishing the remainder of the bits of atomics support that libc++ needs, it probably hasn't been a high priority for him yet.

David

-- Sent from my Apple II