From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 42C543858288; Wed, 30 Nov 2022 23:38:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 42C543858288 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669851520; bh=l13bBDFtzADyNfhoalNktyLnGHNRkpq5ihrlWlJFQcI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SqTOEVjc1vTvdC3kq+XNQU/jAjEbl7Pxkan0h/bp31HokfdjZpV4PplNkG5IgrEMF sQBw4HT8lfm1Wo0RKVZ8ixzgID7kCn3aPM+U2Km/W66rB/QQaId/7RutftWj1tH3vb 6r0vVEuSpAuWmJkOTQnliuykH6Rva8qz3FhMLzEw= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression Date: Wed, 30 Nov 2022 23:38:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.2.1 X-Bugzilla-Keywords: C++-coroutines, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99576 --- Comment #14 from Iain Sandoe --- (In reply to Iain Sandoe from comment #13) > (In reply to Adrian Perl from comment #12) > > I have sent the patch and tests to gcc-patches@gcc.gnu.org >=20 > As noted there, the patch causes regressions in more complex library code > (e.g. some tests in folly) where CONSTRUCTOR trees might have nested await > expressions. >=20 > I mentioned that the real problem is to determine if a temporary should be > promoted - and, in the case of PR95736, the issue is that we promote a > temporary for a target expression that is subsequently elided; we can see > this clearly if we print the object addresses in the test case: >=20 > START TASK > Foo() 0x600001004071 > IN LAMBDA > ~Foo() 0x600001004070 << corresponds to the elided target expression. > ~Foo() 0x600001004071 >=20 >=20 > so this: > diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc > index ce7cf971e03..1bad509233c 100644 > --- a/gcc/cp/coroutines.cc > +++ b/gcc/cp/coroutines.cc > @@ -2830,6 +2830,7 @@ find_interesting_subtree (tree *expr_p, int *dosub, > void *d) > } > } > else if (tmp_target_expr_p (expr) > + && !TARGET_EXPR_ELIDING_P (expr) > && !p->temps_used->contains (expr)) > { > p->entry =3D expr_p; >=20 >=20 > fixes that specific problem - but regresses other test cases (no detailed > analysis yet). Needs more thought .... Turns out the regression was caused by another patch; given Jason's comment= on the gcc-patches thread, this seems worth testing more widely.=