[libcxx-commits] [PATCH] D56913: decoupling Freestanding atomic<T> from libatomic.a

[Olivier Giroux via Phabricator via libcxx-commits]

__simt__ marked an inline comment as done.
__simt__ added inline comments.


================
Comment at: libcxx/include/atomic:1337
+_LIBCPP_INLINE_VISIBILITY 
+_Tp __cxx_atomic_fetch_xor(volatile __cxx_atomic_lock_impl<_Tp>* __a,
+                           _Tp __pattern, memory_order) {
----------------
ldionne wrote:
> It just occurred to me that you define this function (and others) that are only used for the `atomic<Integral>` specialization. Is there a case in which an integral type would be a non-lockfree atomic? Currently, we do not test non-lockfree integral types in the test suite (at least not on my platform, where I don't think there are non-lockfree atomics for integral types).
I'm not aware of any non-lock-free integral or pointer types on a platform that `libcxx` supports at this moment, but it's conceivable. The minimum HW requirement for C++ implementations is to have at least one of: byte test-and-set, or byte exchange. There exist real platforms that come close to this minimum, and would have non-lock-free `atomic_int`.

Also, I tested this code with an override to force almost everything to take the non-lock-free path, even when the lock-free path could have been used. So while it's not exercised via normal testing, I have lightly tested it. Maybe twice. :)

You could keep or delete them, either is OK with me, but personally I'd keep them.


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D56913