From patchwork Thu Apr 7 18:46:14 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Palmer Dabbelt X-Patchwork-Id: 52726 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A51C6385741A for ; Thu, 7 Apr 2022 18:47:14 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 91F4E3858D28 for ; Thu, 7 Apr 2022 18:46:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 91F4E3858D28 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-pl1-x629.google.com with SMTP id o10so5813188ple.7 for ; Thu, 07 Apr 2022 11:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=subject:date:message-id:mime-version:content-transfer-encoding:cc :from:to; bh=WqVFuAotBd3Zm1dl+7wpcbf8ZaKXc68mNurJ/qUW4Yc=; b=a2XuIeCNicVSSe0mN/k5vygWjwEVBgTi6O8+yVBCEVhJHQco/K04wl32e1QeILfYz/ 3RbZYRz0ccqwRTQMcxhKF/yUp/n8zyAmLqYwTeDd29UC6L2ZRV3eKbz0qEqRtGQyZNIY PpxoA6oeYU2uF+o87eoteVf75/VoP2QS3OrogrTfwD0ASSZdTVAKeR6z2uJx33mqHbf8 tc1ReW2K15n97njkxCXI8SVOuDJhmg6hdoLztoJ83JaA+Gw+K467XkyvadSgO69Fo5KD ovm0PWOKDRJtzjuzJuH1iFfMEwWDEq+w7oh0ZeC4TWm9OJ8qa8Msvj0yq+Y/yVad2ZnA B00g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:date:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=WqVFuAotBd3Zm1dl+7wpcbf8ZaKXc68mNurJ/qUW4Yc=; b=WqtNXANFxT35XxqW9CqnKib22NGBp6JsHAiRr6meqmOgDcjOJ/wHkaBpZGqerpIvre 6MW2MYWgIDJnSAecqZLoyyLv9Ge/RSgqPk0ZQLkWM4MSg66iMF8owkb972ye4isIbWkH K9Cqyb+pWT9ntiAVxvzg0IDJsb/2xH84E1xjnPPbYHWw28k0tvCdnyynCApMJS8+fMU0 ukjP6d0SuKoKS73rr5YSUYaP+GCfLwLyr2O7sPHNHO+OVekoat3kly5SqdtbOY+SXrct t/JHjoLi3RPF6QPyex72aK56e/V8EmDcWGbisjMlQ+diX5XZtiKk7Zq7ykPTEQ8Na850 2rnQ== X-Gm-Message-State: AOAM530yWan3XX8kh12Pr5RF7eMQrnJN3p5IB7AW5htyqehuwBjSuuQb LwSAVNV1kh1YHx/dWbz9jv3XqpwrfbbRmw== X-Google-Smtp-Source: ABdhPJzelDFu66lTMHef86VZP4qOgYuycTeUOFzC72rdDZq61XIi+yHKDWLAy0hed+Tq2fK17Zi8Ng== X-Received: by 2002:a17:90b:1b03:b0:1c7:778b:d4ce with SMTP id nu3-20020a17090b1b0300b001c7778bd4cemr17516577pjb.128.1649357216494; Thu, 07 Apr 2022 11:46:56 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id lr6-20020a17090b4b8600b001c7730210e5sm11352239pjb.6.2022.04.07.11.46.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 11:46:56 -0700 (PDT) Subject: [PATCH v1] libstdc++: Default to mutex-based atomics on RISC-V Date: Thu, 7 Apr 2022 11:46:14 -0700 Message-Id: <20220407184614.1216-1-palmer@rivosinc.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" 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. --- 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