From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id A30103857C50 for ; Thu, 14 Apr 2022 15:18:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A30103857C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pj1-x1036.google.com with SMTP id z6-20020a17090a398600b001cb9fca3210so5978259pjb.1 for ; Thu, 14 Apr 2022 08:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=ICuc2pWrxMhpsQ7/+fIdAoRxZfFq242hoE8db/7b5tM=; b=sr4+BK3VE/SE2fLL0gYxym6g676l3Wg56z7BDiEdJ8XHN/fizo7ifImiskl1ebUs+T syDjopMy1NfrEimQ3ovHgBOUffjbzq9r2hulSRsV3RYJPdI1w0hRImouc37kokS+jCAn +AI6sIueDcBmlg876BEgrNVfecmz/Bx975H3Iq8B/hgHp+e5fhCdb6176nySTN1rGIDB /TOFo88B6kLQCBtZb89MIffo4vCfj9vn6OokO9m/G1UNrTxZSGuJKQJFOjcgck7vtRje Nxf99YMAnSmm/CPW5/lN3wcyRi/Nz9Ts7psW8cYTj8o42QyUa6Ry7dPsXQx2aLwpRO47 tjTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=ICuc2pWrxMhpsQ7/+fIdAoRxZfFq242hoE8db/7b5tM=; b=CwYAFeZ557OwzMfB1DD8XDJR6wGdDggCeH6NW9VFZ2WsC+Of4nSqQ4nGDqlpPWpShh Pix3/zNCWza2VnwYH3DeRa+Ym+yLlPXpNuTZNWQypg5apdHeX7aZ9uQ8gFEVCejyLob8 /2SEFuA97rvk0PhPEIqXqAtPK86GKuqx2SChnYLmRJGwvpVMIzO5x475P3RFVj7Smu09 4nGBahezdXw5PU9SYXOcCB8NRLUvIX/p59JXoNwReE8V9JftC/xXd/qhSNYARDoOWpI6 rSqWpmCPSwHk0L16vo8CI7cxZGpO53AYWS8UiFxLgamaU8aMhDMunBpa/Xz2lqSHqCdn D1lQ== X-Gm-Message-State: AOAM533h6aW77iV5SVK97kx6I+qv220lFGl7vF/aqQveNGEttHvHy6c2 b0w0somEl1743+dSKEmU2zzs2g== X-Google-Smtp-Source: ABdhPJzOc+EiWh5wrw8+09GxOPakcKhWcoSQqZeJJCHUzzz5c7OkNKAOKmWjJ15n/drRB96Le+Yb5g== X-Received: by 2002:a17:90b:1bc2:b0:1c9:9cd1:a4fe with SMTP id oa2-20020a17090b1bc200b001c99cd1a4femr4844709pjb.136.1649949502497; Thu, 14 Apr 2022 08:18:22 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id cr12-20020a056a000f0c00b005082b3e087bsm233288pfb.108.2022.04.14.08.18.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 08:18:21 -0700 (PDT) Date: Thu, 14 Apr 2022 08:18:21 -0700 (PDT) X-Google-Original-Date: Thu, 14 Apr 2022 08:18:20 PDT (-0700) Subject: Re: [PATCH v1] libstdc++: Default to mutex-based atomics on RISC-V In-Reply-To: CC: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org From: Palmer Dabbelt To: jwakely@redhat.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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:18:26 -0000 On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwakely@redhat.com wrote: > 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). Thanks, I'll try to remember to look next time. > 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. Ya, that's kind of where I came to as well -- the proper autoconf flavor would scale way better, but hopefully nobody else makes this mistake and thus we don't need to worry about that. I'm fine with either way (though I think we'd need a "riscv*" there, to match riscv32 and riscv64?), so if you want to swap it over (or have me re-spin this) it's no big deal on my end -- also fine, as per below, with you just committing this ;) > 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). That'd be great, thanks! It usually takes me a while to get all the autotools versions lined up (we just got new machines at the office), that way I won't have to do so. > > >>--- >> >>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