From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 4DB643857C50 for ; Thu, 14 Apr 2022 15:08:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DB643857C50 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-231-9sruVmxDOlCp-FCkmln5lQ-1; Thu, 14 Apr 2022 11:08:22 -0400 X-MC-Unique: 9sruVmxDOlCp-FCkmln5lQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 310031C0782B; Thu, 14 Apr 2022 15:08:18 +0000 (UTC) Received: from localhost (unknown [10.33.36.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id E95D720296A5; Thu, 14 Apr 2022 15:08:17 +0000 (UTC) Date: Thu, 14 Apr 2022 16:08:17 +0100 From: Jonathan Wakely To: Palmer Dabbelt Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH v1] libstdc++: Default to mutex-based atomics on RISC-V Message-ID: References: <20220407184614.1216-1-palmer@rivosinc.com> MIME-Version: 1.0 In-Reply-To: <20220407184614.1216-1-palmer@rivosinc.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-14.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 15:08:26 -0000 On 07/04/22 11:46 -0700, Palmer Dabbelt wrote: >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.md (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex > for RISC-V. As documented at https://gcc.gnu.org/lists.html all patches for libstdc++ need to go to the libstdc++ list as well as gcc-patches (otherwise I won't see them). We'd usually do something like: case "${host}" in *-*-riscv) libstdcxx_atomic_lock_policy=mutex ;; *-*-*) AC_TRY_COMPILE([ ... ],,[],[]) esac but this way is simpler. If we add more customization for other targets we can reconsider using the 'case "${host}"' form. So this is OK for trunk, modulo regenerating libstdc++-v3/configure with this change. Let me know if you want me to do that regen for you (or commit the whole thing for you). >--- > >I haven't even built this one, as I'm sure there's a better way to do it >then sticking some more C code in there. >--- > libstdc++-v3/acinclude.m4 | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 >index f53461c85a5..945c0c66f8d 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