On Tue, Jun 30, 2026 at 11:38 PM Jason Merrill <[email protected]> wrote:
> On 6/30/26 11:34 AM, Avi Kivity wrote: > > On Sat, Jun 6, 2026 at 6:31 PM Avi Kivity <[email protected] > > <mailto:[email protected]>> wrote: > > > > From: Avi Kivity <[email protected] <mailto:[email protected]>> > > > > The CWG 2867 implementation introduced conditional cleanup guards for > > structured binding base variables, using internal TARGET_EXPRs. > These > > guard variables are not part of any BIND_EXPR_VARS list, so the > > coroutine frame promotion in register_local_var_uses missed them. > > After a suspend/resume cycle, the guard's stack location is dead, > > causing the conditional destructor to be skipped. > > > > Fix this by introducing TARGET_EXPR_DECOMP_GUARD_P to label > > decomposition > > cleanup guard TARGET_EXPRs at creation time in cp_finish_decl, then > > extending both register_local_var_uses and transform_local_var_uses > to > > detect them and promote their slots to the coroutine frame. > > > > > > Ping on this. Is everyone frightened by the A-word? > > Yes, at this point we're still being conservative about LLM-generated > patches. > > Substantively, this seems like a workaround for an underlying issue with > the collection of variables that need frame promotion; it would be > better to fix to the algorithm, the representation, or both. > > But as you suggested, your patch has inspired me to look more closely at > the issue, so I should have a fix soon. > > > Thanks. I confirm it solves many problems with coroutines and gcc in my project, though one remains. I will try to isolate it later and come up with another wrong-but-inspirational fix. Meanwhile, asking for this fix to be backported.
