public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@vnet.ibm.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Ulrich Weigand <uweigand@de.ibm.com>
Subject: [PATCH, 4.5, 4.6] Fix PR50181 by backporting mainline reload.c patches
Date: Tue, 28 Feb 2012 20:29:00 -0000	[thread overview]
Message-ID: <1330458730.3057.2.camel@otta> (raw)

The following two mainline commits from Andreas fix the two ICEs mentioned
in PR50181 on the 4.5 and 4.6 release branches.  Speaking with Uli offline,
he thought the two patches should be safe enough to backport.

This is a regression from GCC 4.4, so is this ok for 4.6 and 4.5 assuming my
powerpc64-linux bootstraps and regtesting don't show any regressions?

Peter


        PR target/50181
        Backported from mainline

gcc/
	2012-01-20  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	PR rtl-optimization/51856
	* reload.c (find_reloads_subreg_address): Set the address_reloaded
	flag to reloaded.

	2011-03-24  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	* reload.c (find_reloads_subreg_address): Add address_reloaded
	parameter and return true there if the full address has been
	reloaded.
	(find_reloads_toplev): Pass address_reloaded flag.
	(find_reloads_address_1): Don't use address_reloaded parameter.

gcc/testsuite/
	2012-01-20  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

	* gcc.c-torture/compile/pr51856.c: New testcase.


Index: gcc/reload.c
===================================================================
--- gcc/reload.c	(revision 184609)
+++ gcc/reload.c	(working copy)
@@ -285,7 +285,7 @@ static void find_reloads_address_part (r
 				       enum machine_mode, int,
 				       enum reload_type, int);
 static rtx find_reloads_subreg_address (rtx, int, int, enum reload_type,
-					int, rtx);
+					int, rtx, int *);
 static void copy_replacements_1 (rtx *, rtx *, int);
 static int find_inc_amount (rtx, rtx);
 static int refers_to_mem_for_reload_p (rtx);
@@ -4759,7 +4759,7 @@ find_reloads_toplev (rtx x, int opnum, e
 			   || ! offsettable_memref_p (reg_equiv_mem[regno])
 			   || num_not_at_initial_offset))))
 	x = find_reloads_subreg_address (x, 1, opnum, type, ind_levels,
-					 insn);
+					   insn, address_reloaded);
     }
 
   for (copied = 0, i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
@@ -5997,7 +5997,7 @@ find_reloads_address_1 (enum machine_mod
 		{
 		  x = find_reloads_subreg_address (x, 0, opnum,
 						   ADDR_TYPE (type),
-						   ind_levels, insn);
+						   ind_levels, insn, NULL);
 		  push_reload (x, NULL_RTX, loc, (rtx*) 0, rclass,
 			       GET_MODE (x), VOIDmode, 0, 0, opnum, type);
 		  return 1;
@@ -6099,9 +6099,11 @@ find_reloads_address_part (rtx x, rtx *l
 
 static rtx
 find_reloads_subreg_address (rtx x, int force_replace, int opnum,
-			     enum reload_type type, int ind_levels, rtx insn)
+			     enum reload_type type, int ind_levels, rtx insn,
+			     int *address_reloaded)
 {
   int regno = REGNO (SUBREG_REG (x));
+  int reloaded = 0;
 
   if (reg_equiv_memory_loc[regno])
     {
@@ -6125,7 +6127,6 @@ find_reloads_subreg_address (rtx x, int
 	      unsigned inner_size = GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)));
 	      int offset;
 	      rtx orig = tem;
-	      int reloaded;
 
 	      /* For big-endian paradoxical subregs, SUBREG_BYTE does not
 		 hold the correct (negative) byte offset.  */
@@ -6194,11 +6195,13 @@ find_reloads_subreg_address (rtx x, int
 		  && !strict_memory_address_addr_space_p
 			(GET_MODE (x), XEXP (reg_equiv_mem[regno], 0),
 			 MEM_ADDR_SPACE (reg_equiv_mem[regno])))
-		push_reload (XEXP (tem, 0), NULL_RTX, &XEXP (tem, 0), (rtx*) 0,
-			     base_reg_class (GET_MODE (tem), MEM, SCRATCH),
-			     GET_MODE (XEXP (tem, 0)), VOIDmode, 0, 0,
-			     opnum, type);
-
+		{
+		  push_reload (XEXP (tem, 0), NULL_RTX, &XEXP (tem, 0), (rtx*) 0,
+			       base_reg_class (GET_MODE (tem), MEM, SCRATCH),
+			       GET_MODE (XEXP (tem, 0)), VOIDmode, 0, 0,
+			       opnum, type);
+		  reloaded = 1;
+		}
 	      /* If this is not a toplevel operand, find_reloads doesn't see
 		 this substitution.  We have to emit a USE of the pseudo so
 		 that delete_output_reload can see it.  */
@@ -6213,6 +6216,9 @@ find_reloads_subreg_address (rtx x, int
 	    }
 	}
     }
+  if (address_reloaded)
+    *address_reloaded = reloaded;
+
   return x;
 }
 \f
Index: gcc/testsuite/gcc.c-torture/compile/pr51856.c
===================================================================
--- gcc/testsuite/gcc.c-torture/compile/pr51856.c	(revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr51856.c	(revision 0)
@@ -0,0 +1,23 @@
+struct B { int b1; long long b2, b3; int b4; };
+struct C { char c1[40], c2, c3[96]; long long c4[5], c5; char c6[596]; };
+void fn1 (long long), fn2 (char *, int), fn4 (void);
+int r, fn3 (int, const char *, int, char *, int, int);
+
+void
+foo (int t, int u, int v, int w, int x, int y, struct B *z)
+{
+  char c[512], d[512], e;
+  struct C g;
+  long long f, h[255];
+  struct B j;
+  __builtin_bzero (&j, sizeof j);
+  if (y > w)
+    fn4 ();
+  __builtin_bzero (&g, sizeof g);
+  g.c5 = h[0];
+  fn1 (z ? z->b3 : f);
+  g.c2 = y;
+  fn2 (d, 256);
+  if (fn3 (r, "", e, c, 0, 16))
+    fn4 ();
+}


             reply	other threads:[~2012-02-28 19:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 20:29 Peter Bergner [this message]
2012-03-09 16:55 ` Peter Bergner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1330458730.3057.2.camel@otta \
    --to=bergner@vnet.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).