From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id A3F2E3858D20 for ; Wed, 9 Aug 2023 13:12:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A3F2E3858D20 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 52109 invoked from network); 9 Aug 2023 13:12:44 -0000 X-APM-Out-ID: 16915867645210 X-APM-Authkey: 257869/1(257869/1) 6 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 9 Aug 2023 13:12:44 -0000 Content-Type: text/plain; charset=us-ascii 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 14:12:43 +0100 Cc: libstdc++@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B6C385F-6E6A-4EC2-92CC-FD7EB8E553D7@sandoe.co.uk> References: <0B281969-EB24-405E-B41A-83429CDDA8FE@sandoe.co.uk> 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: > On 9 Aug 2023, at 13:53, Jonathan Wakely = wrote: >=20 > On Wed, 9 Aug 2023 at 13:51, Iain Sandoe wrote: >>=20 >>> On 9 Aug 2023, at 13:38, Jonathan Wakely = wrote: >>>=20 >>> On Wed, 9 Aug 2023 at 13:22, Iain Sandoe wrote: >>>> =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. >>=20 >> 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. >>=20 >>> Something like the abi_tag transition for std::string in GCC 5 would = be needed. >>=20 >> That sounds quite complicated and likely to produce similar pain? >=20 > Not nearly as complicated (since we don't use std::call_once > throughout the entire library) but it would still cause pain for the > ecosystem. I was, at one stage, considering the idea of [the new impl] copying the = trampoline lambda address to the (old) =3D> __once_call and the closure = address to (old) __once_callable and then amending __once_proxy to = handle this. It would still be broken w.r.t. nested call_once cases, but no more = broken than existing. However, that means lying about the signature of the old __once_call. .. and it does not solve the issue that the size of the once_flag has = changed. >> =3D=3D=3D=3D >>=20 >> 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). >=20 > We do need to fix PR 99341 somehow, I just don't know how. yeah, tricky. that PR shows as closed, FWIW - but as noted at the start I think = x86_64-linux-gnu is also broken w.r.t once-called fns throwing Iain