https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We define them as:
#ifdef __cpp_lib_atomic_lock_free_type_aliases
# ifdef _GLIBCXX_HAVE_PLATFORM_WAIT
using atomic_signed_lock_free
= atomic<make_signed_t<__detail::__platform_wait_t>>;
using atomic_unsigned_lock_free
= atomic<make_unsigned_t<__detail::__platform_wait_t>>;
# elif ATOMIC_INT_LOCK_FREE || !(ATOMIC_LONG_LOCK_FREE ||
ATOMIC_CHAR_LOCK_FREE)
using atomic_signed_lock_free = atomic<signed int>;
using atomic_unsigned_lock_free = atomic<unsigned int>;
# elif ATOMIC_LONG_LOCK_FREE
using atomic_signed_lock_free = atomic<signed long>;
using atomic_unsigned_lock_free = atomic<unsigned long>;
# elif ATOMIC_CHAR_LOCK_FREE
using atomic_signed_lock_free = atomic<signed char>;
using atomic_unsigned_lock_free = atomic<unsigned char>;
# else
# error "libstdc++ bug: no lock-free atomics but they were emitted in
<version>"
# endif
#endif
And then test them with:
static_assert( std::atomic_signed_lock_free::is_always_lock_free );
static_assert( std::atomic_unsigned_lock_free::is_always_lock_free );
I assume the problem is that the ATOMIC_xxx_LOCK_FREE macros have value 1 not
2, so they're not unconditionally lock-free.
Are any of the atomic integer types always lock-free for this target?
