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 4F7F53858D1E for ; Wed, 30 Nov 2022 08:51:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F7F53858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 874 invoked from network); 30 Nov 2022 08:51:03 -0000 X-APM-Out-ID: 16697982630087 X-APM-Authkey: 257869/1(257869/1) 3 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 30 Nov 2022 08:51:03 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH] coroutines: Fix promotion of class members in co_await statements [PR99576] From: Iain Sandoe In-Reply-To: Date: Wed, 30 Nov 2022 08:51:03 +0000 Cc: GCC Patches , Jason Merrill Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Perl X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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 Adrian, > On 28 Nov 2022, at 20:44, Iain Sandoe wrote: >> Bootstrapping and running the testsuite on x86_64 was successfull. No = regression occured. >=20 > This looks resonable to me, as said in the PR. I=E2=80=99d like to = test a little wider with some larger > codebases, if you could bear with me for a few days. So wider testing (in this case folly) reveals that, although the = analysis seems reasonable, this is not quite the right patch to fix the = issue. It can be that CONSTRUCTORS contain nested await expressions, so = we cannot simply punt on seeing one. My hunch is that the real solution lies in (correctly) deciding whether = to promote the temporary or not. Jason recently made a change that = identifies whether a target expression is expected to be elided (i.e. it = is a direct intializer for another object) - I think this might help in = this case. My concern is whether I should read =E2=80=9Cexpected to be = elided=E2=80=9D to be a guarantee (=E2=80=9Cexpected=E2=80=9D to me = could also be read =E2=80=9Cbut it might not be=E2=80=9D). As is, the patch is not OK since it regresses cases with nested await = expressions in CONSTRUCTORS. sorry for not spotting that sooner, Iain