Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
FireFox317 opened this issue Oct 5, 2020 · 11 comments
Labels
arch-arm 32-bit ARM bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. upstream An issue with a third party project that Zig uses. zig cc Zig as a drop-in C compiler feature
Milestone

Comments

@FireFox317
Copy link
Contributor

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
Copy link
Contributor Author

Issue has been found:

zig/lib/libcxx/include/atomic

Lines 2764 to 2781 in 7067764

#if ATOMIC_LLONG_LOCK_FREE == 2
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, long long>::type __libcpp_signed_lock_free;
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, unsigned long long>::type __libcpp_unsigned_lock_free;
#elif ATOMIC_INT_LOCK_FREE == 2
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, int>::type __libcpp_signed_lock_free;
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, unsigned int>::type __libcpp_unsigned_lock_free;
#elif ATOMIC_SHORT_LOCK_FREE == 2
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, short>::type __libcpp_signed_lock_free;
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, unsigned short>::type __libcpp_unsigned_lock_free;
#elif ATOMIC_CHAR_LOCK_FREE == 2
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, char>::type __libcpp_signed_lock_free;
typedef conditional<_LIBCPP_CONTENTION_LOCK_FREE, __cxx_contention_t, unsigned char>::type __libcpp_unsigned_lock_free;
#else
// No signed/unsigned lock-free types
#endif
typedef atomic<__libcpp_signed_lock_free> atomic_signed_lock_free;
typedef atomic<__libcpp_unsigned_lock_free> atomic_unsigned_lock_free;

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}

@alexnask alexnask added bug Observed behavior contradicts documented or intended behavior zig cc Zig as a drop-in C compiler feature labels Oct 8, 2020
@andrewrk andrewrk added this to the 0.8.0 milestone Oct 13, 2020
@andrewrk andrewrk added the contributor friendly This issue is limited in scope and/or knowledge of Zig internals. label Oct 13, 2020
@andrewrk
Copy link
Member

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.

@andrewrk andrewrk added the upstream An issue with a third party project that Zig uses. label Oct 13, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@andrewrk andrewrk modified the milestones: 0.9.0, 0.8.1 Jan 20, 2021
@andrewrk andrewrk modified the milestones: 0.8.1, 0.9.1 Aug 31, 2021
@andrewrk andrewrk modified the milestones: 0.9.1, 0.9.0, 0.10.0 Nov 20, 2021
@matu3ba
Copy link
Contributor

matu3ba commented Oct 23, 2022

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

@nektro
Copy link
Contributor

nektro commented Oct 23, 2022

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

@andrewrk andrewrk added arch-arm 32-bit ARM backend-llvm The LLVM backend outputs an LLVM IR Module. labels Oct 23, 2022
@alexrp
Copy link
Member

alexrp commented Nov 1, 2022

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
Copy link
Contributor

What is the status of this issue?

Commit 3997828 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
Copy link

bronze1man commented Mar 18, 2023

Simple work around now: use zig 0.9.1

@markus-oberhumer
Copy link
Contributor

Any status update now that llvm16 is merged?

@haohaolee
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

@andrewrk andrewrk removed the backend-llvm The LLVM backend outputs an LLVM IR Module. label Jul 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-arm 32-bit ARM bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. upstream An issue with a third party project that Zig uses. zig cc Zig as a drop-in C compiler feature
Projects
None yet
Development

No branches or pull requests

9 participants