[libcxx] Allow use of <atomic> in baremetal systems when threading is disabled.

[ldionne]

Summary

This will allow embedded projects that provide their own threading library to use the <atomic> library.

[itessier]

Should we just remove the no thread check in <atomic> instead?

[ldionne]

I strongly feel like this should be part of a Freestanding effort with an overarching design. I haven't seen any of this yet.

So: I want this, but I want to know (and agree on) how we're going to do the rest, too.

[jfb]

In D54456#1297067, @ldionne wrote:

I strongly feel like this should be part of a Freestanding effort with an overarching design. I haven't seen any of this yet.

So: I want this, but I want to know (and agree on) how we're going to do the rest, too.

I absolutely agree. The C++ committee has an ongoing effort to define "freestanding" better, and atomic is tentatively part of this. In particular, you really have to figure out what to do with atomics which aren't lock-free, you can't just turn it on without a rationale.

I don't think we want to move forward with this without being close to what the committee is doing, otherwise "baremetal" will just be some odd duckling.

This will allow embedded projects that provide their own threading library to use the <atomic> library.

These projects should provide atomics through the compiler's builtins. Is that what they do? Do you have details? Are there testbots to ensure we don't break that configuration?

[itessier]

I absolutely agree. The C++ committee has an ongoing effort to define "freestanding" better, and atomic is tentatively part of this. In particular, you really have to figure out what to do with atomics which aren't lock-free, you can't just turn it on without a rationale.

Ah, I didn't know there was a freestanding effort, thanks for that info.

These projects should provide atomics through the compiler's builtins. Is that what they do? Do you have details? Are there testbots to ensure we don't break that configuration?

This is for our C++ firmware that already uses std::atomic. We were using libstdc++ (where <atomic> can be used on its own), but have switched to libc++.

[ldionne]

If we're not moving forward with this patch, can it be abandoned? I'd like to clean up the libc++ review queue.

[ldionne]

[Github PR transition cleanup]

Commandeering to close per the above.

CMakeLists.txt

 option(LIBCXX_HAS_PTHREAD_API "Ignore auto-detection and force use of pthread API" OFF)
 option(LIBCXX_HAS_WIN32_THREAD_API "Ignore auto-detection and force use of win32 thread API" OFF)
 option(LIBCXX_HAS_EXTERNAL_THREAD_API
   "Build libc++ with an externalized threading API.
    This option may only be set to ON when LIBCXX_ENABLE_THREADS=ON." OFF)
 option(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
     "Build libc++ with an externalized threading library.
      This option may only be set to ON when LIBCXX_ENABLE_THREADS=ON" OFF)
+option(LIBCXX_BAREMETAL "Build libc++ for baremetal targets." OFF)
 
 # Misc options ----------------------------------------------------------------
 # FIXME: Turn -pedantic back ON. It is currently off because it warns
 # about #include_next which is used everywhere.
 option(LIBCXX_ENABLE_PEDANTIC "Compile with pedantic enabled." OFF)
 option(LIBCXX_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
 option(LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS "Disable #warnings about conflicting macros." OFF)
 

 config_define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
 
 config_define_if(LIBCXX_HAS_PTHREAD_API _LIBCPP_HAS_THREAD_API_PTHREAD)
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_HAS_WIN32_THREAD_API _LIBCPP_HAS_THREAD_API_WIN32)
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 config_define_if(LIBCXX_NO_VCRUNTIME _LIBCPP_NO_VCRUNTIME)
+config_define_if(LIBCXX_BAREMETAL _LIBCPP_BAREMETAL)
 
 if (LIBCXX_ABI_DEFINES)
   set(abi_defines)
   foreach (abi_define ${LIBCXX_ABI_DEFINES})
     if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
       message(SEND_ERROR "Invalid ABI macro ${abi_define} in LIBCXX_ABI_DEFINES")
     endif()
     list(APPEND abi_defines "#define ${abi_define}")

include/atomic

 #include <cstdint>
 #include <type_traits>
 #include <version>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #pragma GCC system_header
 #endif
 
-#ifdef _LIBCPP_HAS_NO_THREADS
+#if defined(_LIBCPP_HAS_NO_THREADS) && !defined(_LIBCPP_BAREMETAL)
 #error <atomic> is not supported on this single threaded system
 #endif
 #if !defined(_LIBCPP_HAS_C_ATOMIC_IMP) && !defined(_LIBCPP_HAS_GCC_ATOMIC_IMP)
 #error <atomic> is not implemented
 #endif
 #ifdef kill_dependency
 #error C++ standard library is incompatible with <stdatomic.h>
 #endif

test/libcxx/atomic_baremetal.sh.cpp

+//===----------------------------------------------------------------------===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+// Test that we can include <atomic> with no threads while targeting baremetal.
+
+// RUN: %build -D_LIBCPP_HAS_NO_THREADS -D_LIBCPP_BAREMETAL
+// RUN: %run
+
+#include <atomic>
+
+int main()
+{
+}