llvm11: clang error when building c++ hello world on arm-linux-musleabi -mcpu=generic+v6kz (__libcpp_signed_lock_free)

[FireFox317]

When building a simple c++ hello world with llvm11 branch (llvm 11.0.0-rc5) (zig c++ example-cc.cpp -target arm-linux-musleabi -mcpu=generic+v6kz):

#include <iostream>
int main() {
std::cout << "Hello\n";
}

We get the following error:

In file included from /home/timonkr/zig-bootstrap/out/host/lib/zig/libcxx/include/memory:681:
/home/timonkr/zig-bootstrap/out/host/lib/zig/libcxx/include/atomic:2780:16: error: use of undeclared identifier '__libcpp_signed_lock_free'
typedef atomic<__libcpp_signed_lock_free> atomic_signed_lock_free;
               ^
/home/timonkr/zig-bootstrap/out/host/lib/zig/libcxx/include/atomic:2781:16: error: use of undeclared identifier '__libcpp_unsigned_lock_free'
typedef atomic<__libcpp_unsigned_lock_free> atomic_unsigned_lock_free;

Related: https://reviews.llvm.org/D75183

cc @LemonBoy

[FireFox317]

Issue has been found: https://github.com/ziglang/zig/blob/7067764ed3f85eca17be7310b848ad97bd8af52e/lib/libcxx/include/atomic#L2764-L2781 Apparently on arm none of the ATOMIC_{}_LOCK_FREE are set to 2 thus there is no support for signed/unsigned lock-free types. But in that case typedef atomic<__libcpp_signed_lock_free> atomic_signed_lock_free; should not be defined.

llvm-project trunk does not have a fix for this, so the following patch has to be applied:

diff --git a/zig/lib/libcxx/include/atomic b/zig/lib/libcxx/include/atomic
index 9c2898653..bf037726f 100644
--- a/zig/lib/libcxx/include/atomic
+++ b/zig/lib/libcxx/include/atomic
@@ -2775,10 +2775,15 @@ typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, char>::typ
 typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, unsigned char>::type      __libcpp_unsigned_lock_free;
 #else
     // No signed/unsigned lock-free types
+#define LOCK_FREE_NOT_AVAILABLE
 #endif
 
+#ifndef LOCK_FREE_NOT_AVAILABLE
 typedef atomic<__libcpp_signed_lock_free> atomic_signed_lock_free;
 typedef atomic<__libcpp_unsigned_lock_free> atomic_unsigned_lock_free;
+#endif
+
+#undef LOCK_FREE_NOT_AVAILABLE
 
 #define ATOMIC_FLAG_INIT {false}
 #define ATOMIC_VAR_INIT(__v) {__v}

[andrewrk]

We can carry this patch, but first it should be sent upstream and accepted upstream so that we will eventually merge our fork back to match upstream with the next release.

[matu3ba]

This deserves to be tagged backend-llvm and arch-arm.

[nektro]

https://reviews.llvm.org/D75183 sent upstream but seems abandoned atm for lack of tests included in patch if anyone wants to resume the work later

[alexrp]

Just checking: Is it expected that, with 0.10.0, I now get:

$ cat main.cxx
#include <iostream>

int main()
{
    std::cout << "Hello World" << std::endl;
}
$ zig c++ main.cxx -target arm-linux-musleabihf
warning(compilation): libc++ does not work on multi-threaded ARM yet.
For more details: https://github.com/ziglang/zig/issues/6573
error: unable to create compilation: TargetRequiresSingleThreaded

? This used to compile fine with 0.9.1.

[markus-oberhumer]

What is the status of this issue?

Commit 3997828a6176 just added a fatal error in src/Compilation.zig for ARM.

And it seems there is no way to test if this is fixed in current libc++ because you cannot set -fsingle-threaded when using zig cc.

[bronze1man]

Simple work around now: use zig 0.9.1

• I use golang+cgo with zig cross to compile from mac os amd64 to linux armv7l (Raspberry Pi 4 Model B).
• I have confirmed that :
  • zig-macos-x86_64-0.9.1.tar.xz work .
  • brew install zig not work (0.10.1)
  • https://ziglang.org/builds/zig-macos-x86_64-0.11.0-dev.1987+a2c6ecd6d.tar.xz not work.

[markus-oberhumer]

Any status update now that llvm16 is merged?

[haohaolee]

It seems this issue has been fixed in https://reviews.llvm.org/D118391 Can we have zig unblock this limitation in the new version?

[haohaolee]

Hi folks, I have tested the latest master zig-bootstrap (llvm 16.0.1), with the limitation above unlocked, and I can successfully compile a c++ program for the target arm-linux-musleabihf now.

I can try to create a PR for this, but I am not sure if removing the limitation part is enough.

[markus-oberhumer]

@haohaolee Yes, please go ahead so that we can fix any possible problems - the current situation prevents any testing at all!