Skip to content

[libc++] Fix std::atomic::wait ulock wait UL_COMPARE_AND_WAIT64 #92783

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

Merged
merged 8 commits into from
Jun 1, 2024
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions libcxx/src/atomic.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -69,17 +69,17 @@ extern "C" int __ulock_wait(
uint32_t operation, void* addr, uint64_t value, uint32_t timeout); /* timeout is specified in microseconds */
extern "C" int __ulock_wake(uint32_t operation, void* addr, uint64_t wake_value);

# define UL_COMPARE_AND_WAIT 1
# define UL_COMPARE_AND_WAIT64 5
# define ULF_WAKE_ALL 0x00000100

static void
__libcpp_platform_wait_on_address(__cxx_atomic_contention_t const volatile* __ptr, __cxx_contention_t __val) {
__ulock_wait(UL_COMPARE_AND_WAIT, const_cast<__cxx_atomic_contention_t*>(__ptr), __val, 0);
__ulock_wait(UL_COMPARE_AND_WAIT64, const_cast<__cxx_atomic_contention_t*>(__ptr), __val, 0);
}

static void __libcpp_platform_wake_by_address(__cxx_atomic_contention_t const volatile* __ptr, bool __notify_one) {
__ulock_wake(
UL_COMPARE_AND_WAIT | (__notify_one ? 0 : ULF_WAKE_ALL), const_cast<__cxx_atomic_contention_t*>(__ptr), 0);
UL_COMPARE_AND_WAIT64 | (__notify_one ? 0 : ULF_WAKE_ALL), const_cast<__cxx_atomic_contention_t*>(__ptr), 0);
}

#elif defined(__FreeBSD__) && __SIZEOF_LONG__ == 8
Expand Down
32 changes: 32 additions & 0 deletions libcxx/test/libcxx/atomics/atomics.syn/wait.pass.cpp
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
//===----------------------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
// UNSUPPORTED: c++03, c++11, c++14, c++17
// UNSUPPORTED: no-threads
// XFAIL: availability-synchronization_library-missing
// This bug was first fixed in LLVM 19
// XFAIL: using-built-library-before-llvm-19
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About the CI failures:

The apple-system CI job should be renamed to something like apple-flavor or something like that. Then,

  • It defines stdlib=apple-libc++ because it's the apple-configured flavor
  • It does NOT define stdlib=system, because we are NOT running against the system-provided library

The back-deployment CI jobs running on Apple would then define stdlib=system and target=<arch>-apple-macosx<version>.

We also need something that implicitly defines stdlib=apple-libc++ whenever we have stdlib=system and a target of macosx (or we could set the feature manually too).

I'll work on that patch, this is just self notes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just turn this into UNSUPPORTED since the apple-backdeployment-hardening looks like it would require very tedious checking of the software versions and maybe even hardware.


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// This bug was first fixed in LLVM 19
// XFAIL: using-built-library-before-llvm-19

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming that implies "Darwin"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://buildkite.com/llvm-project/libcxx-ci/builds/35617#018fc382-8cf3-45dc-a8c8-c3c9d9ccd245

Unfortunately we have "unexpected passes" because of this line. It seems that the CI "Apple system" does have this feature

using-built-library-before-llvm-19

and from what I can see, it is linking against the just built libc++ which has the fix in it

-L /Users/libcxx-buildkite-agent/libcxx.buildkite-agent/builds/f1-1-macminivault-com/llvm-project/libcxx-ci/build/apple-system/arm64/lib -lc++

#include <atomic>
#include <cassert>

void test_85107() {
if constexpr (sizeof(std::__cxx_contention_t) == 8 && sizeof(long) > 4) {
// https://github.com/llvm/llvm-project/issues/85107
// [libc++] atomic_wait uses UL_COMPARE_AND_WAIT when it should use UL_COMPARE_AND_WAIT64 on Darwin
constexpr std::__cxx_contention_t old_val = 0;
constexpr std::__cxx_contention_t new_val = old_val + (1l << 32);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately the if constexpr doesn't really help us here, since it's not a template, all of the semantic checking is still done it seems. Which is what's causing the windows builds to fail (it appears).

Changing the 1l to 1ll might help stop the complaining, and since we're basically asserting that sizeof(long) > 4, it seems like a change that shouldn't change the meaning?

std::__cxx_atomic_contention_t ct(new_val);
std::__libcpp_atomic_wait(&ct, old_val); // this will hang forever if the bug is present
}
}

int main(int, char**) {
test_85107();

return 0;
}
Loading