[libcxx-commits] [libcxx] [libc++] Fix `std::atomic::wait` ulock wait UL_COMPARE_AND_WAIT64 (PR #92783)
via libcxx-commits
libcxx-commits at lists.llvm.org
Wed May 29 11:52:11 PDT 2024
================
@@ -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
+
+#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);
----------------
EricWF wrote:
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?
https://github.com/llvm/llvm-project/pull/92783
More information about the libcxx-commits
mailing list