From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by sourceware.org (Postfix) with ESMTPS id 8D7323858D20 for ; Wed, 9 Aug 2023 12:51:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D7323858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sandoe.co.uk Received: (qmail 81067 invoked from network); 9 Aug 2023 12:51:49 -0000 X-APM-Out-ID: 16915855098106 X-APM-Authkey: 257869/1(257869/1) 4 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 9 Aug 2023 12:51:49 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: [RFA/C] Reimplementation of std::call_once. From: Iain Sandoe In-Reply-To: Date: Wed, 9 Aug 2023 13:51:48 +0100 Cc: libstdc++@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <0B281969-EB24-405E-B41A-83429CDDA8FE@sandoe.co.uk> References: To: Jonathan Wakely X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Jonathan, > On 9 Aug 2023, at 13:38, Jonathan Wakely = wrote: >=20 > On Wed, 9 Aug 2023 at 13:22, Iain Sandoe wrote: >>=20 >> Hello. >>=20 >> With the current [posix-y] implementation of std::call_once, we are = seeing significant issues for Darwin. The issues vary in strength from = =E2=80=9Changs or segvs sometimes depending on optimisation and the day = of the week=E2=80=9D (newer OS, faster h/w) to =E2=80=9Csegvs or = std::terminates every time=E2=80=9D older OS slower h/w. >>=20 >> Actually, I think that in the presence of exceptions it is not = working on Linux either. >>=20 >> As a use-case: this problem prevents us from building working = LLVM/clang tools on Darwin using GCC as the bootstrap compiler. >>=20 >> the test code I am using is: https://godbolt.org/z/Mxcnv9YEx (derived = from a cppreference example, IIRC). >>=20 >> This is a prototype, so I=E2=80=99m looking for advice/comment on: >>=20 >> (a) if this can be generalised to be part of libstdc++ >> (b) what that would take ... >> (c) ..or if I should figure out how to make this a darwin-specific = impl. >=20 >=20 > It's an ABI break. I already tried to replace std::call_once once, see > r11-4691-g93e79ed391b9c6 and r11-7688-g6ee24638ed0ad5 and PR 99341. blast. >> =E2=80=94=E2=80=94 here is the prototype implementation as a = non-patch .. (patch attached). >>=20 >> =3D=3D=3D=3D=3D >> the implementation in mutex.cc can sit togethe with the old version = so that the symbols for that remain available (or, for versioned = libraries, the old code can be deleted). >=20 > If you have old and new code sharing a std::once_flag object you're = dead. indeed - I was only considering the case where existing binaries needed = to run with the new lib, not the case where code compiled with two = different impls was combined. > Something like the abi_tag transition for std::string in GCC 5 would = be needed. That sounds quite complicated and likely to produce similar pain? =3D=3D=3D=3D Presumably an alternative is that I just have to accept that Darwin = needs to use a versioned library (which is a direction I am close to = heading in because of co-existence of mulitple c++ runtimes anyway). thanks Iain