From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 70A583857364 for ; Thu, 14 Apr 2022 15:24:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70A583857364 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-pf1-x430.google.com with SMTP id b15so5158403pfm.5 for ; Thu, 14 Apr 2022 08:24:15 -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=4cOIstgnB+eJAT9MPokc8Pdz/GpT6GgPM3SV2PLTDQk=; b=rmWqotHNq5rIIppnicxzXydXWGjlc0o1thKPLaeH7WDd8K8ZpkM9PPwXodGCDIsH+n utWYUjIIfGN/A8EC2PG7vBdzvYTUkoOCcAnXEGt7C5WiD35GHwN97PWof8nxhUqw4tuu ma9ky/L2RoAsD9w1SJNmu72GCyH6Pofb5qGGSc0dXHuFp/lk9iisgFIBmosByTfXc0ho IqahSCS/1BJC7ST521SqUMI2zFTns9yywF0hPWMtHm6LFIrN20f9TjCinkgPf2eHWK5n 6PkDuRgF1LZpwxirY+fsuC6LVFdiYRDKUPsXQXvf718mW3aGjFrw6TY1PbEF9X+zSxzv yJBA== 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=4cOIstgnB+eJAT9MPokc8Pdz/GpT6GgPM3SV2PLTDQk=; b=tUXJ3Mz7VSkBp9XEYOdj22FYJCR7kKKo7eH4grmJDWmSXkrs4brmvM9ZCgGwSMkK5s 8t3l56tPB7SDANoVFDrCe4isTjAV7iB6190SO1PcN1MOnAvAPy+1tpfKsWR8HA9VTOMK Fquwmhz19eUHy7ttW0MuQxTQKVL3/7kAzm8Tjgo4HKC47WxDLWIGbhpKqRpvvcWmrYHi bzyJt7Te17SZKAWE16svV541P3Er+zAmA8sGvF6TWHDzC6PwRZlfqNGP//D4J12vAi73 9ihtvBgTsBP1SRFxATpGPLTSZScUza0sXS4I+kVHbuLBMPlbn1ZOGDtX+5l8bMMEsXaQ iA4w== X-Gm-Message-State: AOAM532yzAgXoO6iLDYy0vnW8QkVSmAMkrEbcHlog1VdiN1LIuKc5Zjb kOwVSMlEv90UUjPAadv+YQlVng== X-Google-Smtp-Source: ABdhPJxt/Z6y5MNUjzWWAHQ9aqOxWUCIhAxuI/XM/IjPRdPz1fjtZMeqg+/40Ce2p55Msr0XX2cweA== X-Received: by 2002:a62:fb0e:0:b0:505:fd9e:9218 with SMTP id x14-20020a62fb0e000000b00505fd9e9218mr4527451pfm.78.1649949854395; Thu, 14 Apr 2022 08:24:14 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id ne24-20020a17090b375800b001cb62235013sm2237705pjb.5.2022.04.14.08.24.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 08:24:14 -0700 (PDT) Date: Thu, 14 Apr 2022 08:24:14 -0700 (PDT) X-Google-Original-Date: Thu, 14 Apr 2022 08:24:08 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=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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:24:17 -0000 On Thu, 14 Apr 2022 08:22:05 PDT (-0700), jwakely@redhat.com wrote: > On Thu, 14 Apr 2022 at 16:18, Palmer Dabbelt wrote: >> >> 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 ;) > > Yeah, I figured *-*-riscv probably wasn't right, so that's another > reason to prefer your approach. > > >> >> > 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. > > No problem, I can regen+push for you. Great, thanks!