public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
Date: Tue, 03 Nov 2020 18:45:07 +0000	[thread overview]
Message-ID: <bug-66146-4-xQCLbnSbbU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-66146-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #32 from CVS 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:93e79ed391b9c636f087e6eb7e70f14963cd10ad

commit r11-4691-g93e79ed391b9c636f087e6eb7e70f14963cd10ad
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 3 18:44:32 2020 +0000

    libstdc++: Rewrite std::call_once to use futexes [PR 66146]

    The current implementation of std::call_once uses pthread_once, which
    only meets the C++ requirements when compiled with support for
    exceptions. For most glibc targets and all non-glibc targets,
    pthread_once does not work correctly if the init_routine exits via an
    exception. The pthread_once_t object is left in the "active" state, and
    any later attempts to run another init_routine will block forever.

    This change makes std::call_once work correctly for Linux targets, by
    replacing the use of pthread_once with a futex, based on the code from
    __cxa_guard_acquire. For both glibc and musl, the Linux implementation
    of pthread_once is already based on futexes, and pthread_once_t is just
    a typedef for int, so this change does not alter the layout of
    std::once_flag. By choosing the values for the int appropriately, the
    new code is even ABI compatible. Code that calls the old implementation
    of std::call_once will use pthread_once to manipulate the int, while new
    code will use the new std::once_flag members to manipulate it, but they
    should interoperate correctly. In both cases, the int is initially zero,
    has the lowest bit set when there is an active execution, and equals 2
    after a successful returning execution. The difference with the new code
    is that exceptional exceptions are correctly detected and the int is
    reset to zero.

    The __cxa_guard_acquire code (and musl's pthread_once) use an additional
    state to say there are other threads waiting. This allows the futex wake
    syscall to be skipped if there is no contention. Glibc doesn't use a
    waiter bit, so we have to unconditionally issue the wake in order to be
    compatible with code calling the old std::call_once that uses Glibc's
    pthread_once. If we know that we're using musl (and musl's pthread_once
    doesn't change) it would be possible to set a waiting state and check
    for it in std::once_flag::_M_finish(bool), but this patch doesn't do
    that.

    This doesn't fix the bug for non-linux targets. A similar approach could
    be used for targets where we know the definition of pthread_once_t is a
    mutex and an integer. We could make once_flag._M_activate() use
    pthread_mutex_lock on the mutex member within the pthread_once_t, and
    then only set the integer if the execution finishes, and then unlock the
    mutex. That would require careful study of each target's pthread_once
    implementation and that work is left for a later date.

    This also fixes PR 55394 because pthread_once is no longer needed, and
    PR 84323 because the fast path is now just an atomic load.

    As a consequence of the new implementation that doesn't use
    pthread_once, we can also make std::call_once work for targets with no
    gthreads support. The code for the single-threaded implementation
    follows the same methods as on Linux, but with no need for atomics or
    futexes.

    libstdc++-v3/ChangeLog:

            PR libstdc++/55394
            PR libstdc++/66146
            PR libstdc++/84323
            * config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Add new symbols.
            * include/std/mutex [!_GLIBCXX_HAS_GTHREADS] (once_flag): Define
            even when gthreads is not supported.
            (once_flag::_M_once) [_GLIBCXX_HAVE_LINUX_FUTEX]: Change type
            from __gthread_once_t to int.
            (once_flag::_M_passive(), once_flag::_M_activate())
            (once_flag::_M_finish(bool), once_flag::_Active_execution):
            Define new members for futex and non-threaded implementation.
            [_GLIBCXX_HAS_GTHREADS] (once_flag::_Prepare_execution): New
            RAII helper type.
            (call_once): Use new members of once_flag.
            * src/c++11/mutex.cc (std::once_flag::_M_activate): Define.
            (std::once_flag::_M_finish): Define.
            * testsuite/30_threads/call_once/39909.cc: Do not require
            gthreads.
            * testsuite/30_threads/call_once/49668.cc: Likewise.
            * testsuite/30_threads/call_once/60497.cc: Likewise.
            * testsuite/30_threads/call_once/call_once1.cc: Likewise.
            * testsuite/30_threads/call_once/dr2442.cc: Likewise.
            * testsuite/30_threads/call_once/once_flag.cc: Add test for
            constexpr constructor.
            * testsuite/30_threads/call_once/66146.cc: New test.
            * testsuite/30_threads/call_once/constexpr.cc: Removed.
            * testsuite/30_threads/once_flag/cons/constexpr.cc: Removed.

  parent reply	other threads:[~2020-11-03 18:45 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 18:31 [Bug libstdc++/66146] New: " andrey.vul at gmail dot com
2015-05-15  8:55 ` [Bug libstdc++/66146] " redi at gcc dot gnu.org
2015-05-15 15:12 ` andrey.vul at gmail dot com
2015-05-15 17:40 ` msebor at gcc dot gnu.org
2015-05-15 20:31 ` redi at gcc dot gnu.org
2015-05-19 17:36 ` andrey.vul at gmail dot com
2015-05-20  0:11 ` msebor at gcc dot gnu.org
2015-05-20 14:12 ` redi at gcc dot gnu.org
2015-05-20 14:36 ` bugdal at aerifal dot cx
2015-05-20 14:46 ` jakub at gcc dot gnu.org
2015-05-20 14:47 ` redi at gcc dot gnu.org
2015-05-20 14:51 ` bugdal at aerifal dot cx
2020-05-07 11:56 ` jakub at gcc dot gnu.org
2020-06-27 18:18 ` pdimov at gmail dot com
2020-07-09  8:52 ` redi at gcc dot gnu.org
2020-08-27 13:56 ` kisha-nik at mail dot ru
2020-11-03 14:51 ` redi at gcc dot gnu.org
2020-11-03 18:45 ` cvs-commit at gcc dot gnu.org [this message]
2020-11-03 18:46 ` redi at gcc dot gnu.org
2020-11-03 18:46 ` redi at gcc dot gnu.org
2020-11-03 20:17 ` redi at gcc dot gnu.org
2020-12-17  9:08 ` tschwinge at gcc dot gnu.org
2020-12-17  9:58 ` redi at gcc dot gnu.org
2020-12-17 14:03 ` cvs-commit at gcc dot gnu.org
2021-02-04 15:16 ` libor.bukata at oracle dot com
2021-02-11  8:00 ` libor.bukata at oracle dot com
2021-02-11 13:29 ` redi at gcc dot gnu.org
2021-02-15 13:03 ` redi at gcc dot gnu.org
2021-02-15 14:13 ` bugdal at aerifal dot cx
2021-02-15 15:00 ` redi at gcc dot gnu.org
2021-02-15 17:08 ` bugdal at aerifal dot cx
2021-02-15 17:10 ` fw at gcc dot gnu.org
2021-02-15 17:30 ` bugdal at aerifal dot cx
2021-03-16 12:39 ` cvs-commit at gcc dot gnu.org
2021-04-07  6:22 ` unlvsur at live dot com
2021-04-07 10:03 ` redi at gcc dot gnu.org
2021-04-19 10:40 ` redi at gcc dot gnu.org
2021-04-27 11:37 ` jakub at gcc dot gnu.org
2021-07-28  7:04 ` rguenth at gcc dot gnu.org
2022-02-10 23:20 ` redi at gcc dot gnu.org
2022-02-10 23:29 ` redi at gcc dot gnu.org
2022-12-02  1:25 ` lh_mouse at 126 dot com
2022-12-03  9:26 ` redi at gcc dot gnu.org
2024-03-14 11:55 ` cvs-commit at gcc dot gnu.org
2024-03-18 11:22 ` cvs-commit at gcc dot gnu.org
2024-03-18 14:03 ` cvs-commit at gcc dot gnu.org
2024-05-13  9:04 ` [Bug libstdc++/66146] call_once not C++11-compliant iains at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-66146-4-xQCLbnSbbU@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).