https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 > > --- Comment #9 from Iain Buclaw <ibuclaw at gdcproject dot org> --- > (In reply to Jan Hubicka from comment #8) > > > Current workaround I'm using locally for the time being is to call > > > thunk_info::process_early_thunks if the particular branch where this ICE > > > happens is hit. > > > > Why D frontend needs to expand the thunk early and does not rely on > > backend to handle it same way as C++ does? It would be most practical > > if both was finalizing same way. > > > > If there is good reason for not doing so and there is no PCH in D > > frontend we could just add argument to expand_thunk to avoid the game o > > putting things into a vector. > > > > Not discounting that I may be doing it wrong. The call to expand_thunk is > there so that thunks for externally defined methods are generated. > > As the backend usually doesn't emit such thunks, a gimple generated thunk is > forced by the frontend. > > I have seen linker errors in the past when this was not done, however there > could be some alignment with what C++ does to handle this though. Aha, thanks for explanation. In C++ thunks was always connected to the actual function so for external symbols we indeed do not produce the thunk. How does the symbols look like? So you have external symbol and a thunk associated to it with different visibility? What it is? I see that if you expand it to gimple you turn it to normal function and it will be output then. We could do that at the finalization time avoiding the need for additional hacks in the frontend/middleend interface. Honza
