[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

[ibuclaw at gdcproject dot org]

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

--- Comment #11 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Jan Hubicka from comment #10)
> > 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?

Because this is what the reference D compiler does, thunks are static (in the C
sense) and connected with the class definition, where it is referenced by the
class vtable symbol.

However, I have for the past week been trialling out thunks that are global and
emitted only if the function has a definition as well as per what you described
about C++ thunks.

The only drawback I've found so far is that thunks for extern(C++) classes are
left undefined, however I can resolve this by implementing mangle support in
the D front-end so that the C++ generated thunks can be referenced directly.