-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
[libc++] Floating Point Atomic #67799
Conversation
1a8bc86
to
317d84b
Compare
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/lockfree.pass.cpp
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/ctor.pass.cpp
Outdated
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/ctor.pass.cpp
Outdated
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/ctor.pass.cpp
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/fetch_add.pass.cpp
Show resolved
Hide resolved
✅ With the latest revision this PR passed the C/C++ code formatter. |
libcxx/test/libcxx/atomics/atomics.types.generic/atomics.types.float/locakfree.pass.cpp
Outdated
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/assign.pass.cpp
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/test_helper.h
Outdated
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/assign.pass.cpp
Show resolved
Hide resolved
.../test/std/atomics/atomics.types.generic/atomics.types.float/compare_exchange_strong.pass.cpp
Outdated
Show resolved
Hide resolved
173b3f4
to
21057f5
Compare
✅ With the latest revision this PR passed the Python code formatter. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once CI is passing and the temporary tests have been cleaned up. Thanks a lot for all the digging you had to do to make this work, it's really non-trivial! It would be great to get some attention on #47978, maybe we should ping the clang or compiler-rt folks there.
...xx/test/std/atomics/atomics.types.generic/atomics.types.float/compare_exchange_weak.pass.cpp
Outdated
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/test_helper.h
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's ship this.
There are a few things that don't work especially with long double
. However, this patch doesn't make the situation any worse than it already is, since people can already witness the broken behavior with e.g. atomic<long double>::load()
today. I think this patch is in a really good shape and the fixes on top are going to be Clang or compiler-rt fixes.
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/assign.pass.cpp
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/assign.pass.cpp
Show resolved
Hide resolved
libcxx/test/std/atomics/atomics.types.generic/atomics.types.float/assign.pass.cpp
Show resolved
Hide resolved
- implement P0020R6 Floating Point Atomic Differential Revision: https://reviews.llvm.org/D153981
beac256
to
33de815
Compare
// UNSUPPORTED: c++03, c++11, c++14, c++17 | ||
// UNSUPPORTED: target={{.+}}-windows-gnu | ||
// Clang's support for atomic operations on long double is broken. See https://github.com/llvm/llvm-project/issues/72893 | ||
// XFAIL: tsan, msan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like they hang, so XFAIL needs to be UNSUPPORTED
We started seeing tests failures after this patch:
|
This is likely because our tests didn't reference that function before (our tests for atomics were very very naive). But that function should be provided by compiler-rt. Can you dig into it a bit more? This isn't something wrong with this patch per se, it's probably something wrong with the testing configuration on Fuchsia (which might be attributable to libc++'s config or not). |
@huixie90 it's landed breaking msan tsan even presubmit failed them "37 of 40 checks passed" |
Let's take this discussion to #73152. |
Hmm, I just looked and the
The So I'm not certain @huixie90 bypassed any checks he should not have bypassed due to ongoing flakes as part of merging this. I'm not claiming this means those tests aren't broken on tsan/msan, I'm just saying the information we have with the checks on this patch doesn't allow claiming that. |
Never mind, libcxx actions failed different tests, I have no idea if they are related. |
Hi, I am a bit confused now. I looked at the UI under this tab and it was all green. (That was how I check if anything failed before). But It does seem that the UI changed a bit |
This adds a few UNSUPPORTED annotations for tests that hang on some msan bots: https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-bootstrap-msan https://lab.llvm.org/buildbot/#/builders/sanitizer-aarch64-linux-bootstrap-msan We still haven't figured out the root cause of them hanging on these bots but not on the main libc++ CI infra.
@ldionne our CI used to be under this "show all checks" button but now it is gone |
To be clear, this is a Fuchsia Clang toolchain, but the test is actually failing on Linux so it's not Fuchsia-specific. What's somewhat unusual for our toolchain is that we ship I see neither |
Hello, the test is conditionally adding -latomic if compiling a dummy programme with -latomic return 0. In Libc++ CI, on Linux -latomic would be valid so it would add -latomic in the test. On Mac, -latomic would make the dummy program fail to compile/link , so it would not add the flag. But the test link fine without the flag. I guess in Fushia, the -latomic dummy program test returned false , so it did not add the flag. What is the right way to link under fushia ? |
To emphasize again, we're seeing this issue on Linux and not on Fuchsia. The existing llvm-project/libcxx/utils/libcxx/test/features.py Lines 113 to 122 in 48f5855
|
Actually, is there a reason why we even need to link against any of these libraries manually? Why doesn't Clang link against compiler-rt automatically? It does that for other system libraries by default, why is the atomic support library treated differently? |
Undo a part of #73152. These test do not hang, but unexpectedlty pass on aarch64 https://lab.llvm.org/buildbot/#/builders/74/builds/23708 Tests work on aarch64 and probably any platform without fp80.
I think we got to the bottom of it with Hui just now. He's going to upload a patch soon that should address this issue. Note that these tests are going to be disabled on platforms like Fuchsia where we don't know how to get |
Just for clarity; the issue that @petrhosek has reported wasn’t about Fuchsia, it is the Fuchsia team’s toolchain build, targeting Linux - the issue lies in, AFAIK, what library to link in for atomics. But a fix that disables those tests if unable to link in working atomics probably is right in any case. |
These tests are hanging on my Gentoo amd64 machine:
I've killed them after they were running at 100% CPU utilization for over 20 minutes. Full output (after killing)
|
We really shouldn't be depending on far away configuration options like LLVM_HAVE_LINK_VERSION_SCRIPT here. This patch simplifies the enablement of the linker scripts and as a result gets rid of an undesirable dependency on HandleLLVMOptions.cmake. As a drive-by, the patch also stops taking into account whether Python3 is available. This should have no bearing on whether we generate a linker script or not, which is required for correctness. If someone tries to build libc++ and generate a linker script but Python3 is not available, they should get an error instead of silently getting an incorrect installation of the library.
Can you get a stacktrace in the deadlock condition @mgorny ? |
Note that I think this is "resolved" now. @huixie90 turned off the tests that were broken for |
Differential Revision: https://reviews.llvm.org/D153981