[Bug libstdc++/120527] Native platform wait on darwin

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:45477b791daf72d62dd0d7dbc72e8a3cb66391e5

commit r16-7962-g45477b791daf72d62dd0d7dbc72e8a3cb66391e5
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 25 14:29:50 2025 +0000

    libstdc++: Add platform wait functions for FreeBSD [PR120527]

    This defines __platform_wait, __platform_notify, and
    __platform_wait_until for FreeBSD, making use of the _umtx_op syscall.

    The Linux versions of those functions only support 32-bit integers, but
    the FreeBSD versions use the syscall for both 32-bit and 64-bit types,
    as the _umtx_op supports both.

    We also need to change __spin_impl because it currently assumes the
    waitable at args._M_obj is always a __platform_wait_t. Because FreeBSD
    supports waiting on both 32-bit and 64-bit integers, we need a
    platform-specific function for loading a value from _M_obj.  This adds a
    new __platform_load function, which does an atomic load of the right
    size. The Linux definition just loads an int, but for FreeBSD it depends
    on _M_obj_size. We also need a generic version of the function for
    platforms without __platform_wait, because __spin_impl is always used,
    even when the __waitable_state contains a condition_variable.

    libstdc++-v3/ChangeLog:

            PR libstdc++/120527
            * include/bits/atomic_wait.h [__FreeBSD__] (__platform_wait_t):
            Define typedef.
            [__FreeBSD__] (__platform_wait_uses_type): Define variable
            template.
            * src/c++20/atomic.cc (__platform_load): New function.
            [__FreeBSD__] (_GLIBCXX_HAVE_PLATFORM_WAIT, __platform_wait)
            (__platform_notify, __platform_wait_until): Define.
            (__detail::__spin_impl): Use __platform_load.

    Reviewed-by: Tomasz KamiÅski <tkaminsk@redhat.com>