From: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
James Greenhalgh <james.greenhalgh@arm.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341
Date: Tue, 27 Jun 2017 01:20:00 -0000 [thread overview]
Message-ID: <CAELXzTMS9eHrcQ5SxXq4CuipBX4hgqrcYXapSxnAwanXL0AWqA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00614.html added this
workaround to get kernel building with when TARGET_FIX_ERR_A53_843419
is enabled.
This was added to support building kernel loadable modules. In kernel,
when CONFIG_ARM64_ERRATUM_843419 is selected, the relocation needed
for ADRP/LDR (R_AARCH64_ADR_PREL_PG_HI21 and
R_AARCH64_ADR_PREL_PG_HI21_NC are removed from the kernel to avoid
loading objects with possibly offending sequence). Thus, it could only
support pc relative literal loads.
However, the following patch was posted to kernel to add
-mpc-relative-literal-loads
http://www.spinics.net/lists/arm-kernel/msg476149.html
-mpc-relative-literal-loads is unconditionally added to the kernel
build as can be seen from:
https://github.com/torvalds/linux/blob/master/arch/arm64/Makefile
Therefore this patch removes the hunk so that applications like
SPECcpu2017's 521/621.wrf can be built (with LTO in this case) without
-mno-pc-relative-literal-loads
Bootstrapped and regression tested on aarch64-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/testsuite/ChangeLog:
2017-06-27 Kugan Vivekanandarajah <kuganv@linaro.org>
* gcc.target/aarch64/pr63304_1.c: Remove-mno-fix-cortex-a53-843419.
gcc/ChangeLog:
2017-06-27 Kugan Vivekanandarajah <kuganv@linaro.org>
* config/aarch64/aarch64.c (aarch64_override_options_after_change_1):
Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341
for default.
[-- Attachment #2: 0001-Disable-pc-relative-literal-load-irrespective-of-TAR.patch --]
[-- Type: text/x-patch, Size: 1971 bytes --]
From bf5d8151ad6a83903f51529655e83181bdb67200 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
Date: Thu, 8 Jun 2017 15:51:29 +1000
Subject: [PATCH] Disable pc relative literal load irrespective of
TARGET_FIX_ERR_A53_84341
---
gcc/config/aarch64/aarch64.c | 11 -----------
gcc/testsuite/gcc.target/aarch64/pr63304_1.c | 2 +-
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 71f9819..99cfd20 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -8632,17 +8632,6 @@ aarch64_override_options_after_change_1 (struct gcc_options *opts)
if (opts->x_pcrelative_literal_loads == 1)
aarch64_pcrelative_literal_loads = true;
- /* This is PR70113. When building the Linux kernel with
- CONFIG_ARM64_ERRATUM_843419, support for relocations
- R_AARCH64_ADR_PREL_PG_HI21 and R_AARCH64_ADR_PREL_PG_HI21_NC is
- removed from the kernel to avoid loading objects with possibly
- offending sequences. Without -mpc-relative-literal-loads we would
- generate such relocations, preventing the kernel build from
- succeeding. */
- if (opts->x_pcrelative_literal_loads == 2
- && TARGET_FIX_ERR_A53_843419)
- aarch64_pcrelative_literal_loads = true;
-
/* In the tiny memory model it makes no sense to disallow PC relative
literal pool loads. */
if (aarch64_cmodel == AARCH64_CMODEL_TINY
diff --git a/gcc/testsuite/gcc.target/aarch64/pr63304_1.c b/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
index c917f81c..fa0fb56 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
@@ -1,5 +1,5 @@
/* { dg-do assemble } */
-/* { dg-options "-O1 --save-temps -mno-fix-cortex-a53-843419" } */
+/* { dg-options "-O1 --save-temps" } */
#pragma GCC push_options
#pragma GCC target ("+nothing+simd, cmodel=small")
--
2.7.4
next reply other threads:[~2017-06-27 1:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-27 1:20 Kugan Vivekanandarajah [this message]
2017-06-27 8:01 ` Ramana Radhakrishnan
2017-06-28 1:02 ` Kugan Vivekanandarajah
2017-06-28 22:06 ` Ramana Radhakrishnan
2017-07-21 10:12 ` Kugan Vivekanandarajah
2017-08-11 10:34 ` Kugan Vivekanandarajah
2017-08-29 8:32 ` Kugan Vivekanandarajah
2017-08-29 12:02 ` James Greenhalgh
2017-08-30 9:05 ` Kugan Vivekanandarajah
2018-03-07 1:59 ` Kugan Vivekanandarajah
2018-03-07 10:35 ` James Greenhalgh
2017-08-11 13:07 Wilco Dijkstra
2017-08-11 13:08 ` Yvan Roux
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=CAELXzTMS9eHrcQ5SxXq4CuipBX4hgqrcYXapSxnAwanXL0AWqA@mail.gmail.com \
--to=kugan.vivekanandarajah@linaro.org \
--cc=Richard.Earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=james.greenhalgh@arm.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).