On Mon, Jan 13, 2014 at 08:21:49AM -0700, Jeff Law wrote:
> On 01/11/14 03:04, Richard Sandiford wrote:
> >Jeff Law writes:
> >>On 01/10/14 14:44, Eric Botcazou wrote:
> In my backend movdi pattern has unfortunately code '0' (depends on pattern
> declaration order). When gcc tried to deter
On 01/11/14 03:04, Richard Sandiford wrote:
Jeff Law writes:
On 01/10/14 14:44, Eric Botcazou wrote:
In my backend movdi pattern has unfortunately code '0' (depends on pattern
declaration order). When gcc tried to determine if my DI regs can be saved
and restore as 'caller saves' (in caller-sa
> FWIW, it was fixed in 4.8 and later by making CODE_FOR_nothing be 0
> and starting the real instructions at 1.
Indeed, thanks for the heads-up:
2012-07-09 Steven Bosscher
* gensupport.c (init_rtx_reader_args_cb): Start counting code
generating patterns from 1 to free up 0 fo
Jeff Law writes:
> On 01/10/14 14:44, Eric Botcazou wrote:
>>> In my backend movdi pattern has unfortunately code '0' (depends on pattern
>>> declaration order). When gcc tried to determine if my DI regs can be saved
>>> and restore as 'caller saves' (in caller-save.c::init_caller_save()) it
>>> f
> I think I found a bug in gcc 4.7.3 in gcc/caller-save.c at line 158 :
>
> gcc_assert (cached_reg_save_code[reg][mode]);
>
> should be :
>
> gcc_assert (cached_reg_save_code[reg][mode] != -1);
>
> because cached_reg_save_code contains INSN_CODES that can be equal to 0
This is PR55036.
> Agreed, but the assert in caller-save is still wrong and ought to be fixed.
Not clear to me: if you just fix it, you won't realize that the cache is
disabled for the code 0 insn. And there might be other parts of the RTL
middle-end expecting non-zero codes.
--
Eric Botcazou
On 01/10/14 14:44, Eric Botcazou wrote:
In my backend movdi pattern has unfortunately code '0' (depends on pattern
declaration order). When gcc tried to determine if my DI regs can be saved
and restore as 'caller saves' (in caller-save.c::init_caller_save()) it
failed on this wrong assertion.
I
> In my backend movdi pattern has unfortunately code '0' (depends on pattern
> declaration order). When gcc tried to determine if my DI regs can be saved
> and restore as 'caller saves' (in caller-save.c::init_caller_save()) it
> failed on this wrong assertion.
I'd arrange for avoiding code 0 inst
