On 24/09/18 10:19, Eric Botcazou wrote:
>> Ah! But that still doesn't explain why you want to skip these passes
>> when building thunks.
>
> They simply don't work because there is no CFG for thunks; I can add a blurb
> about that.
Yes, this needs a comment as it's far from obvious when looking
> Ah! But that still doesn't explain why you want to skip these passes
> when building thunks.
They simply don't work because there is no CFG for thunks; I can add a blurb
about that.
> So is the barrier correct, or isn't it? There's really no two ways
> about this. I don't like arbitrary cha
On 18/09/18 10:00, Eric Botcazou wrote:
>> this seems to contradict your statement above about having to work
>> harder to fix up minipools.
>
> Why? Fixing up minipools is done in the generic ARM reorg pass, not in the
> Thumb reorg pass(es).
>
Ah! But that still doesn't explain why you want
> this seems to contradict your statement above about having to work
> harder to fix up minipools.
Why? Fixing up minipools is done in the generic ARM reorg pass, not in the
Thumb reorg pass(es).
> Why do we need a barrier here unconditionally (ie in the non-longcall case)?
We don't, but it do
On 17/09/18 12:19, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline, 8 and 7 branches. The new, RTL
> implementation of arm32_output_mi_thunk breaks during the libstdc++ build if
> you configure the compiler with -mlong-calls by default:
>
> 0xdb57eb gen_reg_rtx(machine_
Hi,
this is a regression present on mainline, 8 and 7 branches. The new, RTL
implementation of arm32_output_mi_thunk breaks during the libstdc++ build if
you configure the compiler with -mlong-calls by default:
0xdb57eb gen_reg_rtx(machine_mode)
/home/eric/svn/gcc/gcc/emit-rtl.c:1155
0
