public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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


             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).