[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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
> 
> 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.
> 
> 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:
> 
> START TASK
>  Foo() 0x600001004071
> IN LAMBDA
> ~Foo() 0x600001004070  << corresponds to the elided target expression.
> ~Foo() 0x600001004071
> 
> 
> 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 = expr_p;
> 
> 
> 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.