BUG: ICE with recent egcs from CVS on sparc systems

David S. Miller davem@dm.cobaltmicro.com
Mon Sep 21 17:07:00 GMT 1998


   Date: Mon, 21 Sep 1998 14:12:07 +0200 (MET DST)
   From: Manfred Hollstein <manfred@s-direktnet.de>

   The following  happened  with egcs  updated from CVS  as of 1998/09/21
   10:17:00 +0200.

   On sparc-sun-solaris2.5.1 and 2.6:

   (insn 4140 140 141 (set (mem:SI (plus:SI (reg:SI 30 %fp)
		   (const_int -5180)) 0)
	   (reg:SI 26 %i2)) -1 (insn_list 140 (insn_list:REG_DEP_OUTPUT 137 (nil)))
       (nil))
   ../../egcs-19980921/gcc/toplev.c:1365: Internal compiler error in function fatal_insn

The source of this bug seems to be the recent change to reload shown
below.  The case here is that with this change on Sparc, reload has no
opportunity to discover that the stack/frame pointer relative offset
is too large, and itself requires a reload.

I've tried to look for the reasons behind this change, can someone
enlighten me as to why it was needed or what optimizations were being
missed because of the way the code worked before?

I cannot fathom another way to make this work, and if you look the old
code is consistent with the check used in the other parts of reload
for whether to do this or not.

Fri Sep 18 22:52:05 1998  Jeffrey A Law  (law@cygnus.com)

	* reload.c (find_reloads): Do not replace a pseudo with 
	(MEM (reg_equiv_addr)) in the initializing insn for the
	pseudo.

Index: reload.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/reload.c,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- reload.c	1998/09/08 13:42:58	1.43
+++ reload.c	1998/09/18 21:54:39	1.44
@@ -2673,7 +2673,8 @@
 	    substed_operand[i] = recog_operand[i]
 	      = reg_equiv_mem[regno];
 #endif
-	  if (reg_equiv_address[regno] != 0)
+	  if (reg_equiv_address[regno] != 0
+	      && (set == 0 || &SET_DEST (set) != recog_operand_loc[i]))
 	    {
 	      /* If reg_equiv_address is not a constant address, copy it,
 		 since it may be shared.  */




More information about the Gcc-bugs mailing list