[RFA] choosing __platform_wait_t on targets without lock-free 64 atomics
Iain Sandoe
iain@sandoe.co.uk
Thu Dec 29 11:28:45 GMT 2022
Hi,
The recent addition of the tz handling has pulled in a dependency on </bits/atomic_wait.h>
This currently specifies __platform_wait_t as a 64bit quatity on platforms without _GLIBCXX_HAVE_LINUX_FUTEX.
PowerPC does not have a 64b atomic without library support - so that this causes a bootstrap
fail on powerpc-darwin (and I guess any other 32b powerpc non-futex target).
Rather than contrive to build and add libatomic (which is not at present available at the point
that libstdc++ is built), I wonder if there is any specific reason that __platform_wait_t needs
to be 64 bits on these platforms? (Especially since the futex case uses an int.)
Advice on the right way to fix this welcome — as a work-around to allow bootstrap to complete
I applied the patch below - but that seems unlikely to be the right thing generically .
thanks
Iain
----
diff --git a/libstdc++-v3/include/bits/atomic_wait.h b/libstdc++-v3/include/bits/atomic_wait.h
index bd1ed56..2f67180 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -64,7 +64,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// and __platform_notify() if there is a more efficient primitive supported
// by the platform (e.g. __ulock_wait()/__ulock_wake()) which is better than
// a mutex/condvar based wait.
+#if __LP64__
using __platform_wait_t = uint64_t;
+#else
+ using __platform_wait_t = uint32_t;
+#endif
inline constexpr size_t __platform_wait_alignment
= __alignof__(__platform_wait_t);
More information about the Libstdc++
mailing list