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

Al Grant Al.Grant at arm.com
Sun Mar 25 14:42:02 PDT 2012


Hi,

I've been looking at libcxx's <atomic> and experimenting with an implementation
of the low-level intrinsics it uses, as described at

  http://libcxx.llvm.org/atomic_design_a.html

where the intrinsics include

  type __atomic_load(const type* atomic_obj, int mem_ord);

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?

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.

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?

Al

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.





More information about the cfe-dev mailing list