[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