[libcxx-commits] [PATCH] D72240: Implement C++20 std::atomic_ref and test

Olivier Giroux via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Sep 16 16:28:20 PDT 2020


__simt__ added inline comments.


================
Comment at: libcxx/include/atomic:1015
+__cxx_atomic_pointer_to_data(_Tp* __value) {
+  return reinterpret_cast<typename __annotate_with_qualifiers<_Atomic(typename __cxx_atomic_base_impl_traits<_Tp>::__underlying_t), _Tp>::__type*>(&__value->__a_value);
 }
----------------
rsmith wrote:
> I find this cast concerning. There's no guarantee that `_Atomic(T)` is compatible with plain `T` in general (they might have different representations), and even if the layout is identical, I don't think Clang's strict aliasing rules provide a guarantee that you can access a `T` via an `_Atomic(T)`. (We happen to treat atomic types as can-alias-anything right now, but that's only because we've not implemented strict aliasing for atomics yet.)
> 
> Can we use the implementation in terms of `__atomic_*` for `atomic_ref` instead? Those builtins are designed to be used on objects that are declared with type `T` rather than type `_Atomic(T)`.
I agree with you there. It looks like `atomic_ref<>` is not implementable (at least not at high QoI) on top of C11 the way that `atomic<>` was.

I do wish the `_Atomic(T)` path simply wasn't there in libcxx, and we just always used the `__atomic_*` path but the Mac build chooses the `_Atomic(T)` path. At least it does today.

Not sure how to reconcile that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72240/new/

https://reviews.llvm.org/D72240



More information about the libcxx-commits mailing list