suspected bug in reorg.c

[Jeffrey A Law]

  In message < v04011701b1b19489f0e8@[192.168.1.254] >you write:
  > In reorg, it looks to me like the code carefully evaluates the function
  > for the slot, but then in the backward's scan, it pushes the SECOND
  > delay candidate instruction it finds onto the front of the list - so now,
  > the slots aren't aligned with the "case" that matches.
I believe this is done on purpose.  The first candidate found actually
executes last and therefore should be in the last delay slot, additional
candidates are put in earlier delay slots until all the slots are filled.

Thus the order of insns in the delay slots will match their order before
they were moved into the delay slot.


  > As far as I can tell, none of the ports in the EGCS distribution
  > have delay slots like this.
Right.  I don't believe any targets in egcs or gcc2 have more than one
delay slot.  Thus the code to handle mutliple delay slots isn't used
often and thus likely has some bugs.

Seems to me that "slots_filled" isn't the right concept -- somehow we
need to tell eligible_for_delay "we are filling slot # X".



jeff