This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

bug fix for expand_increment


For the mips target, a compiler abort has been observed:

t.i: In function `f':
t.i:2155: internal error--unrecognizable insn:
(insn 661 659 663 (set (reg:DI 266)
        (plus:DI (reg:DI 263)
            (symbol_ref:DI ("a")))) -1 (nil)
    (nil))
IOT trap/Abort

This insn is generated for this source construct:

    a[i]++

expand_increment queues a MEM, and to do this, it puts the address
into a register.  It uses force_reg to do this, and this generates
the unrecognizable insn, because the address is

(plus:DI (reg:DI 263)
    (symbol_ref:DI ("a")))

Here is a fix:

Tue Oct 28 23:47:03 1996  J"orn Rennecke <amylaar@cygnus.co.uk>

	* expr.c (expand_increment): When enqueing a postincrement for a MEM,
	use copy_to_reg if address is not a general_operand.

Index: expr.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/expr.c,v
retrieving revision 1.296
diff -p -r1.296 expr.c
*** expr.c	1996/11/12 23:49:00	1.296
--- expr.c	1997/10/28 23:50:22
*************** expand_increment (exp, post, ignore)
*** 9783,9789 ****
  	}
        if (icode != (int) CODE_FOR_nothing && GET_CODE (op0) == MEM)
  	{
! 	  rtx addr = force_reg (Pmode, XEXP (op0, 0));
  	  rtx temp, result;
  
  	  op0 = change_address (op0, VOIDmode, addr);
--- 9783,9791 ----
  	}
        if (icode != (int) CODE_FOR_nothing && GET_CODE (op0) == MEM)
  	{
! 	  rtx addr = (general_operand (XEXP (op0, 0), mode)
! 		      ? force_reg (Pmode, XEXP (op0, 0))
! 		      : copy_to_reg (XEXP (op0, 0)));
  	  rtx temp, result;
  
  	  op0 = change_address (op0, VOIDmode, addr);



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]