[Bug libstdc++/99537] Wrong memory_order used in stop_token ref-counting

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:ad9ae82ed1c33e1803f33bb367b0b4c9ee2e3e63

commit r10-9594-gad9ae82ed1c33e1803f33bb367b0b4c9ee2e3e63
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Mar 11 16:44:57 2021 +0000

    libstdc++: Use acq_rel memory ordering [PR 99537]

    As Lewis Baker wrote in the PR:

    > The 'fetch_sub()' operation in _M_release_ownership() should be using
    > memory_order::acq_rel instead of memory_order::release. The use of
    > 'release' only is insufficient as it does not synchronise with any
    > corresponding 'acquire' operation.

    > With the current implementation, it's possible that a prior write to
    > one of the _M_value or _M_head data-members by a thread releasing the
    > second-to-last reference might not be visible to another thread that
    > releases the last reference and frees the memory, resulting in
    > potential write to freed memory.

    This simply changes the memory order to acq_rel as suggested.

    libstdc++-v3/ChangeLog:

            PR libstdc++/99537
            * include/std/stop_token (_Stop_state_t::_M_release_ownership):
            Use acq_rel memory ordering.

    (cherry picked from commit 15825b17cf3fbf28181c51fe94a2898f448f915c)