This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

[3.4 PATCH] Fix PR middle-end/18590


Hi,

This is an ICE during the purge_addressof pass, a regression present on the 
3.4 branch.  We start with:

(insn 1718 1717 1720 100 (set (mem/f:SI (addressof:SI (reg/v:SI 52) 51 
0x2a95bf6820) [4 start+0 S4 A16])
        (mem/f:SI (addressof:SI (reg/v:SI 38) 37 0x2a95bf3dd0) [4 endtag+0 S4 
A16])) 25 {*m68k.md:749} (nil)
    (nil))

(insn 1720 1718 6706 100 (set (mem/f:SI (addressof:SI (reg/v:SI 38) 37 
0x2a95bf3dd0) [4 endtag+0 S4 A16])
        (mem/f:SI (addressof:SI (reg/v:SI 52) 51 0x2a95bf6820) [4 start+0 S4 
A16])) 25 {*m68k.md:749} (nil)
    (nil))

which comes from:

                *endtag = oldchar, start = endtag;

                endtag = start;


(reg/v:SI 38) is put into the stack at:

(mem/f:SI (plus:SI (reg/f:SI 14) (const_int -630)))

which gives:

(insn 1718 1717 1720 100 (set (reg/v:SI 52) 51 0x2a95bf6820) [4 start+0 S4 
A16])
        (mem/f:SI (plus:SI (reg/f:SI 14) (const_int -630)))

(insn 1720 1718 6706 100 (set (mem/f:SI (plus:SI (reg/f:SI 14) (const_int 
-630)))
        (reg/v:SI 52) 51 0x2a95bf6820) [4 start+0 S4 A16])) 25 {*m68k.md:749} 
(nil)
    (nil))

and fixup_var_ref_insn is invoked with the new value.  It then deletes insn 
1720 because of insn 1718 and this code

  /* The insn to load VAR from a home in the arglist
     is now a no-op.  When we see it, just delete it.
     Similarly if this is storing VAR from a register from which
     it was loaded in the previous insn.  This will occur
     when an ADDRESSOF was made for an arglist slot.  */
  else if (toplevel
	   && (set = single_set (insn)) != 0
	   && SET_DEST (set) == var
	   /* If this represents the result of an insn group,
	      don't delete the insn.  */
	   && find_reg_note (insn, REG_RETVAL, NULL_RTX) == 0
	   && (rtx_equal_p (SET_SRC (set), var)
	       || (GET_CODE (SET_SRC (set)) == REG
		   && (prev = prev_nonnote_insn (insn)) != 0
		   && (prev_set = single_set (prev)) != 0
		   && SET_DEST (prev_set) == SET_SRC (set)
		   && rtx_equal_p (SET_SRC (prev_set), var))))
    {
      delete_insn (insn);
    }


Then (reg/v:SI 52) is put into the stack at

(mem/f:SI (plus:SI (reg/f:SI 14) (const_int -634)))

insn 1720 was deleted but it is still present in the RTL stream (only 
INSN_DELETED_P is set on it) so it becomes:

(insn 1720 1718 6706 100 (set (mem/f:SI (plus:SI (reg/f:SI 14) (const_int 
-630)))
        (mem/f:SI (plus:SI (reg/f:SI 14) (const_int -634)))

When this insn is being fixed up, the compiler ICEs on a sanity check in 
add_insn_before:

  if (optimize && INSN_DELETED_P (before))
    abort ();


The proposed fix is to teach fixup_var_refs_insns_with_hash not to invoke 
fixup_var_refs_insn on insns that have been deleted if optimization is 
enabled.

Bootstrapped/regtested on amd64-mandrake-linux-gnu.  The testcase is big and I 
didn't manage to reduce it to a reasonable size (I didn't try very hard).


2004-12-05  Eric Botcazou  <ebotcazou@libertysurf.fr>

	Fix PR middle-end/18590
	* function.c (fixup_var_refs_insns_with_hash): Do not invoke
	fixup_var_refs_insn on insns marked as deleted if optimization
	is enabled.


-- 
Eric Botcazou
Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.483.4.19
diff -u -p -r1.483.4.19 function.c
--- function.c	13 Oct 2004 23:18:13 -0000	1.483.4.19
+++ function.c	1 Dec 2004 13:02:19 -0000
@@ -1639,7 +1639,8 @@ fixup_var_refs_insns_with_hash (htab_t h
   tmp.key = var;
   ime = htab_find (ht, &tmp);
   for (insn_list = ime->insns; insn_list != 0; insn_list = XEXP (insn_list, 1))
-    if (INSN_P (XEXP (insn_list, 0)))
+    if (INSN_P (XEXP (insn_list, 0))
+	&& !(optimize && INSN_DELETED_P (XEXP (insn_list, 0))))
       fixup_var_refs_insn (XEXP (insn_list, 0), var, promoted_mode,
 			   unsignedp, 1, may_share);
 }

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