Libcxx cmake warning "Host compiler must support std::atomic!"

I'm seeing the following warning during cmake. I'm not sure when it started. Is this a known issue? Can it be safely ignored?

CMake Warning at projects/libcxx/cmake/Modules/CheckLibcxxAtomic.cmake:49 (message):
  Host compiler must support std::atomic!
Call Stack (most recent call first):
  projects/libcxx/cmake/config-ix.cmake:63 (include)
  projects/libcxx/CMakeLists.txt:476 (include)

It's also showing up in the upstream bots:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-debian/builds/1189/steps/cmake/logs/stdio

The linker errors (in my cmake) are actually:
CMakeFiles/cmTC_354e0.dir/src.cxx.o: In function `__clang_call_terminate':
src.cxx:(.text.__clang_call_terminate[__clang_call_terminate]+0x2): undefined reference to `__cxa_begin_catch'
src.cxx:(.text.__clang_call_terminate[__clang_call_terminate]+0xb): undefined reference to `std::terminate()'
CMakeFiles/cmTC_354e0.dir/src.cxx.o:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
CMakeFiles/cmTC_354e0.dir/build.make:97: recipe for target 'cmTC_354e0' failed

Hello Krzysztof,

I’ve seen these errors in our nightly builds as well and noticed them when tracking down a different set of build breaks last month. I don’t honestly know if they can be safely ignored. Our nightly compilers work for our testing even with the errors. I would be interested in knowing what this means and if it impacts us though.

I did a little digging and found when we started seeing the messages. These SHAs are from the LLVM monorepo (https://github.com/llvm/llvm-project.git). We started seeing them in our builds 2019-March-05. I don’t have the exact commit but may have time tomorrow to dig in a bit more.

b306ef12f04635-master (llvm-svn: 355299) # clean
81dbc02671b223-master (llvm-svn: 355375) # emits “Host compiler must support std::atomic!”

Hello Krzysztof,

I’ve seen these errors in our nightly builds as well and noticed them when tracking down a different set of build breaks last month. I don’t honestly know if they can be safely ignored. Our nightly compilers work for our testing even with the errors. I would be interested in knowing what this means and if it impacts us though.

I did a little digging and found when we started seeing the messages. These SHAs are from the LLVM monorepo (https://github.com/llvm/llvm-project.git). We started seeing them in our builds 2019-March-05. I don’t have the exact commit but may have time tomorrow to dig in a bit more.

b306ef12f04635-master (llvm-svn: 355299) # clean
81dbc02671b223-master (llvm-svn: 355375) # emits "Host compiler must support std::atomic!”

This change?

https://github.com/llvm/llvm-project/commit/81dbc02671b223

It’s an LLDB commit, doesn’t seem related. Maybe an adjacent change was the root cause?

Sorry, I wasn’t clear. I meant the change is somewhere between those two commits: those are two nightly builds 24 hours apart.

I’ve bisected down the previously mentioned commit deltas to the following commit. This is the first instance of the warning message.

https://github.com/llvm/llvm-project/commit/21450545d14

[libc++] decoupling Freestanding atomic from libatomic.a

This patch introduces non-lockfree atomics that do not require using
an external libatomic. This work is done with the long-term goal of
allowing the use of <atomic> in freestanding environments.

Thanks to Olivier Giroux for the patch.
Differential Revision: [https://reviews.llvm.org/D56913](https://reviews.llvm.org/D56913)
 

llvm-svn: 355318

libc+±dev is probably a better list for this discussion. Moving cfe-dev to BCC…

libc+±dev is probably a better list for this discussion. Moving cfe-dev to BCC…

I’ve bisected down the previously mentioned commit deltas to the following commit. This is the first instance of the warning message.

https://github.com/llvm/llvm-project/commit/21450545d14

[libc++] decoupling Freestanding atomic from libatomic.a

This patch introduces non-lockfree atomics that do not require using
an external libatomic. This work is done with the long-term goal of
allowing the use of <atomic> in freestanding environments.

Thanks to Olivier Giroux for the patch.
Differential Revision: [https://reviews.llvm.org/D56913](https://reviews.llvm.org/D56913)
 

llvm-svn: 355318

That commit doesn’t touch the CMake scripts, so I admit I’m a little bit confused.

Louis

That commit doesn't touch the CMake scripts, so I admit I'm a little bit confused.

The cmake scripts will try to identify the presence and location of atomics (plus options required to get them, etc.). If their implementation has changes, the scripts may no longer work correctly. I'm not sure what specifically goes wrong in this case, but something isn't working right.