cc1 crash with -funroll-all-loops analyzed

[Jeffrey A Law]

  In message < 4.2.0.37.19990518111439.036f5260@mail.lauterbach.com >you write:
  > 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)
OK.  So the result of the comparison is a loop invariant and we move the
comparison out of the loop.

  > leaving a conditional jump and it's label behind.
Right.  And when we copy the loop for the unroller we only see the loop, not
any of code in the loop's preheader.  OK.

  > Maybe the unroll code 
  > should check if there are any real insns between the conditional jump and 
  > the label?
Na.  We'll let jump clean that up :-)

I believe the way to fix this is to have can_reverse_comparison_p return zero
when prev_nonnote_insn returns zero.  ie, change:

      rtx prev = prev_nonnote_insn (insn);
      rtx set = single_set (prev);

      if (set == 0 || SET_DEST (set) != arg0)
        return 0;


To something like this:

      rtx prev = prev_nonnote_insn (insn);
      rtx set;

      if (prev == 0)
	return 0;

      set = single_set (prev);     
       
      if (set == 0 || SET_DEST (set) != arg0)
        return 0;


Want to give that a try and see if it fixes the problem?

  > 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):
Ah.  Yes.  I remember that hunk of code :-)  Don't ask.  It is not pleasant.


  > 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?
When an insn is hoisted out of a loop, the new operation still appears in the
rtl chain in the loop's preheader.

  > Ah, that problem :-).
Silly me, I should have read specific.html.  It does recommend upgrading all
of binutils, not just the assembler.  I'll give this a whirl.  Thanks!

jeff