public inbox for libstdc++-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jonathan Wakely <redi@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org
Subject: [gcc r12-8161] libstdc++: Default to mutex-based atomics on RISC-V
Date: Thu, 14 Apr 2022 16:39:13 +0000 (GMT)	[thread overview]
Message-ID: <20220414163913.62285385741A@sourceware.org> (raw)

https://gcc.gnu.org/g:3fc22eedb033cbff1bf5a70c6a032d3c5ce2d867

commit r12-8161-g3fc22eedb033cbff1bf5a70c6a032d3c5ce2d867
Author: Palmer Dabbelt <palmer@rivosinc.com>
Date:   Thu Apr 14 17:22:58 2022 +0100

    libstdc++: Default to mutex-based atomics on RISC-V
    
    The RISC-V port requires libatomic to be linked in order to resolve
    various atomic functions, which results in builds that have
    "--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks.
    Changing this to direct atomics breaks the ABI, this forces the auto
    detection mutex-based atomics on RISC-V in order to avoid a silent ABI
    break for users.
    
    See Bug 84568 for more discussion.  In the long run there may be a way
    to get the higher-performance atomics without an ABI flag day, but
    that's going to be a much more complicated operation.  We don't even
    have support for the inline atomics yet, but given that some folks have
    been discussing hacks to make these libatomic routines appear implicitly
    it seems prudent to just turn off the automatic detection for RISC-V.
    
    libstdc++-v3/ChangeLog:
    
            * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex
            for RISC-V.
            * configure: Regenerate.

Diff:
---
 libstdc++-v3/acinclude.m4 | 3 +++
 libstdc++-v3/configure    | 7 +++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index eac8aeda48b..6aece2adff8 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3612,6 +3612,9 @@ AC_DEFUN([GLIBCXX_ENABLE_LOCK_POLICY], [
     dnl Why don't we check 8-byte CAS for sparc64, where _Atomic_word is long?!
     dnl New targets should only check for CAS for the _Atomic_word type.
     AC_TRY_COMPILE([
+    #if defined __riscv
+    # error "Defaulting to mutex-based locks for ABI compatibility"
+    #endif
     #if ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
     # error "No 2-byte compare-and-swap"
     #elif ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 35dc3f49383..7a0ac405331 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -16193,6 +16193,9 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
                 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+    #if defined __riscv
+    # error "Defaulting to mutex-based locks for ABI compatibility"
+    #endif
     #if ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
     # error "No 2-byte compare-and-swap"
     #elif ! defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
@@ -16240,7 +16243,7 @@ $as_echo "mutex" >&6; }
   # unnecessary for this test.
 
     cat > conftest.$ac_ext << EOF
-#line 16243 "configure"
+#line 16246 "configure"
 int main()
 {
   _Decimal32 d1;
@@ -16282,7 +16285,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
   # unnecessary for this test.
 
   cat > conftest.$ac_ext << EOF
-#line 16285 "configure"
+#line 16288 "configure"
 template<typename T1, typename T2>
   struct same
   { typedef T2 type; };


                 reply	other threads:[~2022-04-14 16:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220414163913.62285385741A@sourceware.org \
    --to=redi@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    --cc=libstdc++-cvs@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).