gcc-4.8: Fix GCC ICE on arm

armv5t was seeing ICE on code from elfutils it has been fixed upstream
so lets backport it.

(From OE-Core rev: 6c50d60ce3fd7242e67a531d5875edeb8b7a3651)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

2 files changed, 67 insertions, 0 deletions

diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc b/meta/recipes-devtools/gcc/gcc-4.8.inc
index 87af783e2c..a9786da97e 100644
--- a/meta/recipes-devtools/gcc/gcc-4.8.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
@@ -65,6 +65,7 @@ SRC_URI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
            file://0033-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch \
            file://0034-Use-the-multilib-config-files-from-B-instead-of-usin.patch \
            file://0035-wcast-qual-PR-55383.patch \
+           file://gcc-4.8-PR56797.patch \
           "
 SRC_URI[md5sum] = "e6040024eb9e761c3bea348d1fa5abb0"
 SRC_URI[sha256sum] = "b037fe5132b71ecad2ea7141ec92292b5d32427bf90fd90cde432b1d5abacc2c"
diff --git a/meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-PR56797.patch b/meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-PR56797.patch
new file mode 100644
index 0000000000..b5d7b864fd
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.8/gcc-4.8-PR56797.patch
@@ -0,0 +1,66 @@
+Upstream-Status: Backport
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+From patchwork Fri Apr 19 09:34:49 2013
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [ARM] Fix PR56797
+Date: Thu, 18 Apr 2013 23:34:49 -0000
+From: Greta Yorsh <Greta.Yorsh@arm.com>
+X-Patchwork-Id: 237891
+Message-Id: <000801ce3ce1$23fbdd60$6bf39820$@yorsh@arm.com>
+To: "GCC Patches" <gcc-patches@gcc.gnu.org>
+Cc: <raj.khem@gmail.com>, "Richard Earnshaw" <Richard.Earnshaw@arm.com>,
+ "Ramana Radhakrishnan" <Ramana.Radhakrishnan@arm.com>
+
+Fix PR56797
+http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56797
+
+The problem is that peephole optimizer thinks it can generate an ldm, but
+the pattern for ldm no longer matches, because after r188738 it requires
+that if one of the destination registers is SP then the base register must
+be SP, and it's not SP in the test case. 
+
+The test case fails on armv5t but doesn't fail on armv6t2 or armv7-a because
+peephole doesn't trigger there (because there is a different epilogue
+sequence). It looks like a latent problem for other architecture or CPUs.
+
+This patch adds this condition to the peephole optimizer.
+
+No regression on qemu for arm-none-eabi and fixes the test reported in the
+PR. I couldn't minimize the test sufficiently to include it in the
+testsuite. 
+
+Ok for trunk?
+
+Thanks,
+Greta
+
+gcc/ 
+
+2013-04-18  Greta Yorsh  <Greta.Yorsh@arm.com>
+        
+        PR target/56797
+        * config/arm/arm.c (load_multiple_sequence): Require SP
+        as base register for loads if SP is in the register list.
+
+
+diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
+index d00849c..60fef78 100644
+--- a/gcc/config/arm/arm.c
++++ b/gcc/config/arm/arm.c
+@@ -10347,6 +10347,13 @@ load_multiple_sequence (rtx *operands, int nops, int *regs, int *saved_order,
+              || (i != nops - 1 && unsorted_regs[i] == base_reg))
+            return 0;
+ 
++          /* Don't allow SP to be loaded unless it is also the base
++             register.  It guarantees that SP is reset correctly when
++             an LDM instruction is interruptted.  Otherwise, we might
++             end up with a corrupt stack.  */
++          if (unsorted_regs[i] == SP_REGNUM && base_reg != SP_REGNUM)
++            return 0;
++
+          unsorted_offsets[i] = INTVAL (offset);
+          if (i == 0 || unsorted_offsets[i] < unsorted_offsets[order[0]])
+            order[0] = i;