On Tue, Jun 26, 2012 at 2:43 AM, Iain Buclaw <ibuclaw at ubuntu dot com> wrote:
> On 19 June 2012 17:08, Steven Bosscher <stevenb dot gcc at gmail dot com> 
> wrote:
>> BTW you also include output.h in those two files, and I am about two
>> patches away from adding output.h to the list of headers that no front
>> end should ever include (a front end should never have to write out
>> assembly). Can you please check what you need output.h for, and fix
>> this?
>>
>>
>> What are you calling targetm.asm_out.output_mi_thunk and
>> targetm.asm_out.generate_internal_label for? Thunks and aliases should
>> go through cgraphunit.
>>
>> (NB: This also means that this front end cannot work with LTO. IMHO we
>> shouldn't let in new front ends that don't work with LTO.)
>>
>>
>
> I tried switching, but unfortunately it broke the code generation of D
> thunks.  D requires any class that inherits from an interface to
> output thunks for that interface regardless of how far back it is and
> whether it being external to the current module.  However, the GCC
> backend as far as I can tell only outputs aliases when the function is
> output as well. So if there is no function to output no thunk will be
> generated.  This leaves a handful of undefined references to thunks
> that were defined in the D frontend, but discarded by the backend.
> Whereas forcing the output using output_mi_thunk means the thunk is
> emitted and does not cause issues.
>
> So removing output.h will be a bit of a problem for me with no obvious
> way around it.

The obvious way around it is to work with this community to fix the
problem. You will want to talk with Jan Hubicka about this, see if he
can help.

Ciao!
Steven

Reply via email to