https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #6) from me there has been no progress on anything co-routines related, for a while - I of not have any resources to work on it. > I am not really expert on coroutines. But this seems to be a type (not a > declaration we globalize during LTO) generated internally by the front-end. > The name __D.9984.3.4 looks like it has a global counter in it. > ODR types are supposed to be literaly the same across units. > > One way to silence this would be to not make these types ODR types since > they are not the usual C++ types anyway. > I wonder if this is a part of the cross-unit API that is supposed to be > same? I.e. is the coroutine in one compilation unit visible from the other? > > If so, perhaps the only problem is hte global counter 9984 and if the counts > were generated internally for each such type, the ODR handling wlll be happy. the synthesised functions (actor, destroy) are intended to be TU-local. the ramp function is what remains of the user's original function after the coroutine body is outlined - so that has the original signature of the user's function. We do use counters to generate local symbol names for frame-promoted temporaries, so I suppose that there is a possibility that the name(s) that are intended to be TU-local become visible across TUs in LTO; but those should be the names of coroutine frame entries (i.e. fields in a structure, not themselves global symbols).
