Re: cc1 crash with -funroll-all-loops analyzed

[Jeffrey A Law <law at upchuck dot cygnus dot com>]

  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 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.

  > 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.

  > >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? 


jeff