Add placeholder __libcpp_relaxed_store() for when atomic builtins are not available.

[dim]

Summary

In rL241532, atomic_support.h was added, which provides handling of
atomic operations for libc++. When atomic builtins are not available,
it emits a warning about being unsupported, but it still provides a
number of stubs for the required functions.

However, it misses a stub for __libcpp_relaxed_store(). Add it, by
using the same implementation as for __libcpp_atomic_store().

(Note that I encountered this on arm-freebsd, which still defaults to
armv4, and does not have the runtime libcalls to support atomic
builtins. For now, I have simply disabled using them.)

[theraven]

Looks fine (though this probably won't actually work correctly on ARMv4).

It's a shame that libc++ decided to reinvent the wheel here and not use the C11 atomics support...

[EricWF]

Does anything actually need this? This interface was never really meant to be complete, just want was needed.

It's a shame that libc++ decided to reinvent the wheel here and not use the C11 atomics support

GCC doesn't provide "_Atomic" and <atomic> isn't always fully available. This is a minimal subset of atomic functionality needed to support std::shared_ptr and std::call_once among other things. All new code should use std::atomic IMO. It's not meant to reinvent the wheel, It's meant to be a portable option for when there is no "wheel" already.

Does armv4 need lib calls for atomic operations on "unsigned long"?

[jroelofs]

In D13051#250836, @EricWF wrote:

Does armv4 need lib calls for atomic operations on "unsigned long"?

IIRC, yes.

[dim]

In D13051#250836, @EricWF wrote:

Does anything actually need this? This interface was never really meant to be complete, just want was needed.

I need it at least for FreeBSD/arm, since it defaults to armv4, and it does not yet have a full set of atomic ops as libcalls. In any case, if stub functions are provided, they should at least compile. :-)

[EricWF]

Ah sorry I hadn't had coffee yet. Sorry for the breakage. I'll make sure this make sure this patch gets backported appropriately.

LGTM thanks for the fix.

[EricWF]

@jroelofs @dim, could we fallback to the __sync_* builtins on arm?

[jroelofs]

In D13051#250910, @EricWF wrote:

@jroelofs @dim, could we fallback to the __sync_* builtins on arm?

@dim would need armv4-flavored implementations of them in compiler-rt (if that's what he's using)... the existing ones use instructions that v4 doesn't have. Implementation-wise, they'd have to use __kuser_cmpxchg. See: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt

[dim]

In D13051#250921, @jroelofs wrote:

In D13051#250910, @EricWF wrote:

@jroelofs @dim, could we fallback to the __sync_* builtins on arm?

The actual implementations of these __sync builtins should still come from somewhere, as they will also be libcalls, right?

@dim would need armv4-flavored implementations of them in compiler-rt (if that's what he's using)... the existing ones use instructions that v4 doesn't have.

Andrew Turner, a fellow FreeBSD developer, has added them pretty quickly, in https://svnweb.freebsd.org/base?view=revision&revision=288125. So I have now reverted the ugly workaround in FreeBSD that disabled _LIBCPP_HAS_ATOMIC_BUILTINS for arm < v6.

src/include/atomic_support.h

 template <class _ValueType, class _FromType>
 inline _LIBCPP_INLINE_VISIBILITY
 void __libcpp_atomic_store(_ValueType* __dest, _FromType __val,
                            int = 0)
 {
     *__dest = __val;
 }
 
+template <class _ValueType, class _FromType>
+inline _LIBCPP_INLINE_VISIBILITY
+void __libcpp_relaxed_store(_ValueType* __dest, _FromType __val)
+{
+    *__dest = __val;
+}
+
 template <class _ValueType>
 inline _LIBCPP_INLINE_VISIBILITY
 _ValueType __libcpp_atomic_load(_ValueType const* __val,
                                 int = 0)
 {
     return *__val;
 }