cc1 crash with -funroll-all-loops analyzed

[Franz Sirl]

At 10:54 18.05.99 , Jeffrey A Law wrote:

>   In message < 99051621512600.00672@ns1102.munich.netsurf.de >you write:
>   > >That's precisely what you need to figure out.  ie, is it valid not 
> to have
>   > >a previous insn which sets (reg:CC 147).
>   >
>   > I guess not :-(.
>In general, I agree, but what I'm trying to determine is, in the context
>of copying a loop body for unrolling can we validly end up with this 
>situation.

I looked closer at it and I think it's a legitimate situation. Basically 
this code is either executed once or endlessly, depending on the value of 
(reg/v:SI 87) and then it is valid to move the 2 insn out of the loop, 
leaving a conditional jump and it's label behind. Maybe the unroll code 
should check if there are any real insns between the conditional jump and 
the label?

>I can imagine ways we could copy those loops where it would be possible, but
>I haven't actually looked at the unroller's code to determine what's 
>happening.
>
>One way to attack this is to find out why the prev insn of the jump was
>turned into a NOTE_INSN_DELETED, then try to work forward to determine if
>we've got a case where we can (temporarily) have a jump insn with no
>previous compare insn.

It was not turned into a NOTE_INSN_DELETED, it was generated by this code 
in copy_loop_body() (around line 1680 in unroll.c):

   start_sequence ();

   /* Emit a NOTE_INSN_DELETED to force at least two insns onto the sequence.
      Else gen_sequence could return a raw pattern for a jump which we pass
      off to emit_insn_before (instead of emit_jump_insn_before) which causes
      a variety of losing behaviors later.  */
   emit_note (0, NOTE_INSN_DELETED);



>   > and accordingly move_movables moves them out of the loop lateron :-(,
>   > leaving a lonely conditional jump behind. Where to go from here? This
>   > bug begins to scare me...
>Hoisting a compare is fine, for a non-cc0 machine that's no different than
>hoisting any other loop invariant.  But we can't hoist the conditional jump
>(one day :-)
>
>But even when we hoist the compare, it should still end up on the insn
>chain before the jump_insn which uses the output of the compare insn.  Thus
>prev_nonnote_insn (jump_insn)) shouldn't return zero.

I don't quite understand that, move_movables() has moved these instructions 
onto lets say insn 332 and 333, and that happened before copy_loop_body() 
was invoked. Now copy_loop_body() generates a insn 334 with a 
NOTE_INSN_DELETED and a insn 335 with the copy of the conditional jump, 
which is the only instruction left in the loop. Are you trying to say that 
insn 333 and 334 should have been linked together?

>   > >BTW, have you been able to bootstrap egcs on linuxppc?
>   >
>   > Currently no problem, I can bootstrap fine on LinuxPPC with -O2/-O2
>Odd.  I have access to a linux-ppc machine right now running linuxppc 4 and
>it blows up, as best as I can tell in xgcc in the macro expanded isalpha
>code.
>
>I've already upgraded the assembler, so that should not be the problem.  ANy
>other ideas to get this thing running?

Ah, that problem :-). That's a linker problem, you need either 
binutils >=2.9.1.0.23 or a current binutils snapshot. I switched DRR1 
(pre-R5) to binutils-990418 to fix this and other problems (strip 
corrupting binaries).

Franz.