From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 509D23852C5E; Sun, 4 Dec 2022 11:08:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 509D23852C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x32b.google.com with SMTP id p13-20020a05600c468d00b003cf8859ed1bso7894344wmo.1; Sun, 04 Dec 2022 03:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=GTsJgPjjQBDDDTZDTAIxoULSaiiQw+RG4+5xa+NYKH0=; b=MYNvFPczuaf67zF+B/Rgxy44a4hXn8ybzJLsI33hzfjXdq/zgkn18XKdPTEcFy6jLh eEm898Mn1y7O3MIdl+fjz0AW4yJSR+CF9hkQj6dzxPbWJ0MUCJOJTIRKFrbBrheOabp3 c6kd98hK4ev49HDrzK5IJr9Ic4/VBoHvMb3q87wBdNCBEmJG9Kqa1KzVCJ7mPbKAqpVL 4qmXfe67QuQn762nzatS09394nKmFkue6BUpmQwrNucQlUdX4EpHET48SbKHOd4thJ1i R4scvhEcalZUMHDBjLsgwkHEKWUgB/LbfW90nd7tYWhul3xpDT+DR9QHgr4WfVRUyrnQ tv3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GTsJgPjjQBDDDTZDTAIxoULSaiiQw+RG4+5xa+NYKH0=; b=1OksVaxhQz/CVe/486YTo3RcLVOlOCc1nKL3dZPayWBY3xkTLc0QkzPIkDMxReOg6R E9NNS5pwBJnODRLF6T8Ey7Fz3WepsMnEFTenuFqzDRf1L166xj1sodd57a4zJqF4RHOm R+fmX9yjR506GP+5W3IB4DUTtW1SFNIocYAGTj0teCBieBHAlwo+VebpvX12Jv48AN+g NgayWERQnkGWePIHwWcG35taN1DI655LKkfS/O4k2/m30Jh3pz+w3+9AzYrWUEM8LLdt 7ZxYREeKL9FKnBrb9z3OgYUSConf3uD/WCLpWG6FjtiDnzTc1elO/2tIzcw9+5g2Gtmp 81vA== X-Gm-Message-State: ANoB5plYVGq0VSHamGXud7w7W8nRSyBVlEXcU99gMsntOuvegNomxi1k qZIJMRCHcaUqGGvVtNREPPh0ZJecI/E= X-Google-Smtp-Source: AA0mqf5bRsDg+iks22YbKLEwdpGGtbjHGMm4cDgAK1SJoUsTFzJJQNXrB317aAN81wrc7Ay61if89w== X-Received: by 2002:a05:600c:31a3:b0:3cf:4757:fc3 with SMTP id s35-20020a05600c31a300b003cf47570fc3mr58250353wmp.172.1670152096931; Sun, 04 Dec 2022 03:08:16 -0800 (PST) Received: from localhost.localdomain (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.gmail.com with ESMTPSA id t2-20020a5d42c2000000b002365b759b65sm11515291wrr.86.2022.12.04.03.08.16 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 04 Dec 2022 03:08:16 -0800 (PST) From: Iain Sandoe X-Google-Original-From: Iain Sandoe To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [PATCH] libstdc++, Darwin: Limit recursive mutex init to OS versions needing it. Date: Sun, 4 Dec 2022 11:08:15 +0000 Message-Id: <20221204110815.34872-1-iain@sandoe.co.uk> X-Mailer: git-send-email 2.37.1 (Apple Git-137.1) Reply-To: iain@sandoe.co.uk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: While looking at Darwin's os_defines, I wondered whether _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC was really still necessary. On checking the OS, it seems that it was a transient problem that only appears in Darwin11. Earlier versions do not have the initializer, and the operation is fixed in Darwin12+. So, I figure we still need the workaround for Darwin8-11 but not later versions (patch implements this). Testing on both earlier and later systems does not (as one might expect) reveal any differences (we still have some lock-related tests that 'twinkle' so that there can be something still hidden by that). Anyway. the question is. "is there any reason not to use the system version of this where it works, or should I just leave the status quo?" If the former, then "ok for master?". thanks Iain -- >8 -- The problem described in pr 51906 was fixed in the next OS release. Limit the workaround to systems that need it. Signed-off-by: Iain Sandoe libstdc++-v3/ChangeLog: * config/os/bsd/darwin/os_defines.h (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro to OS versions that need it. --- libstdc++-v3/config/os/bsd/darwin/os_defines.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/config/os/bsd/darwin/os_defines.h b/libstdc++-v3/config/os/bsd/darwin/os_defines.h index 38fdfb5f6f0..5b611d32e0d 100644 --- a/libstdc++-v3/config/os/bsd/darwin/os_defines.h +++ b/libstdc++-v3/config/os/bsd/darwin/os_defines.h @@ -39,8 +39,12 @@ // implementation is not itself a weak definition). #define _GLIBCXX_WEAK_DEFINITION __attribute__ ((__weak__)) -// Static initializer macro is buggy in darwin, see libstdc++/51906 +#if defined (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) \ + && (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 1080) +// Static initializer macro is absent for Darwin < 11 and buggy in Darwin 11, +// see libstdc++/51906. Fixed in Darwin 12 (OS X 10.8). #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC +#endif // Configure checks for nanosleep fail on Darwin, but nanosleep and // sched_yield are always available, so use them. -- 2.37.1 (Apple Git-137.1)