Re: [bugs] Another ICE

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> > 
> > Content-Description: message body text
> > >
> > > Hi Honza,
> > >
> > > I got another ICE with yesterday evenings version of gcc :-((
> > >
> > > Egbert.
> > >
> > Hi,
> > the bug is caused by gcse, that emits result of gen_move_insn and then update
> > basic block info for last insn. In case gen_move_insn used sequence of insns,
> > others are kept w/o any info.
> > 
> > (hmm, ugly - perhaps we can avoid gcse from using the BASIC_BLOCK_FOR_INSN
> > completely? I can't imagince case gcse is doing transformation and don't know
> > basic block information and keeping that array up-to-date is expensive)
> > 
> > Honza
> > 
> I'm puzzled why doesn't set_block_for_new_insns DTRT because it is supposed to
> handle a sequence. I think your change is just papering over a bug.
> 
> Looking at set_block_for_new_insns I see that it stop scanning backwards if it
> finds a NOTE.
> 
>   /* Scan the previous instructions setting the block number until we find
>      an instruction that has the block number set, or we find a note
>      of any kind.  */
>   for (insn = PREV_INSN (insn); insn != NULL_RTX; insn = PREV_INSN (insn))
>     {
>       if (GET_CODE (insn) == NOTE)
>         break;
> 
>       ....
>     }
> 
> Would the generated sequence by any chance of had a NOTE?
The sequence is:
(sequence[
        (insn 608 0 609 (set (reg/f:DI 181)
                (symbol_ref/u:DI ("*.LC3"))) -1 (nil)
            (expr_list:REG_EQUAL (symbol_ref/u:DI ("*.LC3"))
                (nil)))
        (insn 609 608 0 (set (reg:DF 180)
                (mem/u/f:DF (reg/f:DI 181) 140)) -1 (nil)
            (nil))
    ] )

and set_block_for_new_insns bails out here:

  /* We dont scan to set the block to 0 since this is the default value.
     If we did, we'd end up scanning/setting the entire prologue block
     everytime we insert an insn into it. */
  if (bb->index == 0)
    return;

It is not correct, as the array now seems to contains pointer, not indexes,
so we end up with NULL pointer reference.

I am not quite sure if removing this test is good idea.

Honza

> 
> Graham