[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