summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-4.9
diff options
context:
space:
mode:
authorPeter A. Bigot <pab@pabigot.com>2014-08-14 14:05:52 -0500
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-08-15 18:21:49 +0100
commit7b8b0af1d8ae73077514a6c3759de498827c62d6 (patch)
tree9c98f77c801db298f0240c23a699727b19452d7e /meta/recipes-devtools/gcc/gcc-4.9
parent6d78f392f524944a1e32e14e4b1a7e48422a3ece (diff)
downloadpoky-7b8b0af1d8ae73077514a6c3759de498827c62d6.tar.gz
gcc: remove inappropriate patch
0037-gcc-4.8-PR56797.patch was originally added as an OE backport during 4.8.0. Upstream merged it in 4.8.1, and it was present in 4.9.0. The original patch still applies to 4.9.1 (and presumably 4.8.2), but now is modifying store_multiple_sequence instead of load_multiple_sequence (the two functions are nearly identical). It may or may not be necessary in store_multiple_sequence, but absent a bug report upstream supporting its application in this case, or a least an updated comment and upstream status in the patch, I think this patch should be dropped. (From OE-Core rev: c89443e0f98249b9f9ea33f686c27babe35fd024) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-devtools/gcc/gcc-4.9')
-rw-r--r--meta/recipes-devtools/gcc/gcc-4.9/0037-gcc-4.8-PR56797.patch66
1 files changed, 0 insertions, 66 deletions
diff --git a/meta/recipes-devtools/gcc/gcc-4.9/0037-gcc-4.8-PR56797.patch b/meta/recipes-devtools/gcc/gcc-4.9/0037-gcc-4.8-PR56797.patch
deleted file mode 100644
index b5d7b864fd..0000000000
--- a/meta/recipes-devtools/gcc/gcc-4.9/0037-gcc-4.8-PR56797.patch
+++ /dev/null
@@ -1,66 +0,0 @@
1Upstream-Status: Backport
2Signed-off-by: Khem Raj <raj.khem@gmail.com>
3
4From patchwork Fri Apr 19 09:34:49 2013
5Content-Type: text/plain; charset="utf-8"
6MIME-Version: 1.0
7Content-Transfer-Encoding: 7bit
8Subject: [ARM] Fix PR56797
9Date: Thu, 18 Apr 2013 23:34:49 -0000
10From: Greta Yorsh <Greta.Yorsh@arm.com>
11X-Patchwork-Id: 237891
12Message-Id: <000801ce3ce1$23fbdd60$6bf39820$@yorsh@arm.com>
13To: "GCC Patches" <gcc-patches@gcc.gnu.org>
14Cc: <raj.khem@gmail.com>, "Richard Earnshaw" <Richard.Earnshaw@arm.com>,
15 "Ramana Radhakrishnan" <Ramana.Radhakrishnan@arm.com>
16
17Fix PR56797
18http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56797
19
20The problem is that peephole optimizer thinks it can generate an ldm, but
21the pattern for ldm no longer matches, because after r188738 it requires
22that if one of the destination registers is SP then the base register must
23be SP, and it's not SP in the test case.
24
25The test case fails on armv5t but doesn't fail on armv6t2 or armv7-a because
26peephole doesn't trigger there (because there is a different epilogue
27sequence). It looks like a latent problem for other architecture or CPUs.
28
29This patch adds this condition to the peephole optimizer.
30
31No regression on qemu for arm-none-eabi and fixes the test reported in the
32PR. I couldn't minimize the test sufficiently to include it in the
33testsuite.
34
35Ok for trunk?
36
37Thanks,
38Greta
39
40gcc/
41
422013-04-18 Greta Yorsh <Greta.Yorsh@arm.com>
43
44 PR target/56797
45 * config/arm/arm.c (load_multiple_sequence): Require SP
46 as base register for loads if SP is in the register list.
47
48
49diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
50index d00849c..60fef78 100644
51--- a/gcc/config/arm/arm.c
52+++ b/gcc/config/arm/arm.c
53@@ -10347,6 +10347,13 @@ load_multiple_sequence (rtx *operands, int nops, int *regs, int *saved_order,
54 || (i != nops - 1 && unsorted_regs[i] == base_reg))
55 return 0;
56
57+ /* Don't allow SP to be loaded unless it is also the base
58+ register. It guarantees that SP is reset correctly when
59+ an LDM instruction is interruptted. Otherwise, we might
60+ end up with a corrupt stack. */
61+ if (unsorted_regs[i] == SP_REGNUM && base_reg != SP_REGNUM)
62+ return 0;
63+
64 unsorted_offsets[i] = INTVAL (offset);
65 if (i == 0 || unsorted_offsets[i] < unsorted_offsets[order[0]])
66 order[0] = i;