https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- hmm. __D.9984.3.4 means that this is a frame variable that is a 'promoted' temporary (promoted because its lifetime had to be extended across a suspend point by copying it into the frame). So, I am supposing that this issue is because such a temporary would almost certainly not have the same DECL_UID (from which the __D.xxxx is created) in different TUs. Which seems to imply that we need to find a way to disambiguate the frame variable names for LTO. This is, I would expect, another case of something with local visibility becoming globally visible for LTO (but that's supposition, not analysed). the coros testsuite runs torture tests thus: .... PASS: g++.dg/coroutines/torture/alloc-00-gro-on-alloc-fail.C -O2 -flto -flto-partition=none (test for excess errors) PASS: g++.dg/coroutines/torture/alloc-00-gro-on-alloc-fail.C -O2 -flto -flto-partition=none execution test PASS: g++.dg/coroutines/torture/alloc-00-gro-on-alloc-fail.C -O2 -flto (test for excess errors) PASS: g++.dg/coroutines/torture/alloc-00-gro-on-alloc-fail.C -O2 -flto execution test so there is some coverage of LTO - but not multiple TUs :(.