Yet another reload_reg_free_for_value_p bug

[Jeffrey A Law]

  In message <Pine.LNX.4.10.9909211146170.8349-100000@biriani.cygnus.co.uk>you 
  > The situation is as follows (it's an i386 toolchain):
  > 
  > reg_last_reload_reg[59] == %edx
  > 
  > Reload 0: reload_in (SI) = (reg:SI 59)
  > 	  GENERAL_REGS, RELOAD_FOR_OTHER_ADDRESS (opnum = 1)
  > 	  reload_in_reg: (reg:SI 59)
  > Reload 1: reload_in (SI) = (reg/v:SI 5 %edi)
  > 	  reload_out (SI) = (reg/v:SI 1 %edx)
  > 	  DREG, RELOAD_OTHER (opnum = 0)
  > 	  reload_in_reg: (reg/v:SI 5 %edi)
  > 	  reload_out_reg: (reg/v:SI 1 %edx)
  > 	  reload_reg_rtx: (reg/v:SI 1 %edx)
  > Reload 2: reload_in (SI) = (mem/f:SI (reg:SI 59) 0)
  > 	  reload_out (SI) = (reg/v:SI 62)
  > 	  CREG, RELOAD_OTHER (opnum = 1)
  > 	  reload_in_reg: (mem/f:SI (reg:SI 59) 0)
  > 	  reload_out_reg: (reg/v:SI 62)
  > 
  > choose_reloads goes on and selects %ecx for reload 2 and %edx for reload 1
  > (it doesn't have a choice).  Things go wrong when it tries to find a
  > register for reload 0.  Since the value of reg 59 is still lying around in
  > %edx (see reg_last_reload_reg), it tries to use that as reload register.  T
  > o
  > determine whether that's valid, it calls reload_reg_free_for_value_p.  This
  > function fails to see that reload 0 conflicts with reload 1, and returns 1
  > to indicate that it's perfectly OK to use %edx - which is wrong.
  > 
  > The patch below changes reload_reg_free_for_value_p to correct this
  > (reloads_conflict already shows that RELOAD_FOR_OTHER_ADDRESS reloads
  > conflict with RELOAD_OTHER reloads).
  > 
  > Bernd
  > 
  > 	* reload1.c (reload_reg_free_for_value_p): Show
  > 	RELOAD_FOR_OTHER_ADDRESS reloads can conflict with RELOAD_OTHER
  > 	reloads.
Thanks.  Between Joern and your comments I think this is the most reasonable
thing to do short term until we can revamp this code to be cleaner.

I went ahead and installed this change.

jeff