public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>,
	 James Greenhalgh <james.greenhalgh@arm.com>,
	Marcus Shawcroft <marcus.shawcroft@arm.com>
Subject: [PATCH][AArch64][GCC 6] PR target/79041: Correct -mpc-relative-literal-loads logic in aarch64_classify_symbol
Date: Wed, 11 Jan 2017 16:32:00 -0000	[thread overview]
Message-ID: <58765E2D.5030609@foss.arm.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

Hi all,

In this PR we generated ADRP/ADD instructions with :lo12: relocations on symbols even though -mpc-relative-literal-loads
is used. This is due to the confusing double-negative logic of the
nopcrelative_literal_loads aarch64 variable and its relation to the aarch64_nopcrelative_literal_loads global variable
in the GCC 6 branch.

Wilco fixed this on trunk as part of a larger patch (r237607) and parts of that patch were backported, but other parts weren't and
that patch now doesn't apply cleanly to the branch.

The actual bug here is that aarch64_classify_symbol uses nopcrelative_literal_loads instead of the correct aarch64_nopcrelative_literal_loads.
nopcrelative_literal_loads gets set to 1 if the user specifies -mpc-relative-literal-loads(!) whereas aarch64_nopcrelative_literal_loads gets
set to false, so that is the variable we want to check.

So this is the minimal patch that fixes this.

Bootstrapped and tested on aarch64-none-linux-gnu on the GCC 6 branch.

Ok for the branch?

Thanks,
Kyrill

2017-01-11  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR target/79041
     * config/aarch64/aarch64.c (aarch64_classify_symbol): Use
     aarch64_nopcrelative_literal_loads instead of
     nopcrelative_literal_loads.

2017-01-11  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     PR target/79041
     * gcc.target/aarch64/pr79041.c: New test.

[-- Attachment #2: tmp.patch --]
[-- Type: text/x-patch, Size: 1385 bytes --]

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 83dbd57..fa61289 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9324,7 +9324,7 @@ aarch64_classify_symbol (rtx x, rtx offset)
 	  /* This is alright even in PIC code as the constant
 	     pool reference is always PC relative and within
 	     the same translation unit.  */
-	  if (nopcrelative_literal_loads
+	  if (aarch64_nopcrelative_literal_loads
 	      && CONSTANT_POOL_ADDRESS_P (x))
 	    return SYMBOL_SMALL_ABSOLUTE;
 	  else
diff --git a/gcc/testsuite/gcc.target/aarch64/pr79041.c b/gcc/testsuite/gcc.target/aarch64/pr79041.c
new file mode 100644
index 0000000..a23b1ae
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr79041.c
@@ -0,0 +1,26 @@
+/* PR target/79041.  Check that we don't generate the LO12 relocations
+   for -mpc-relative-literal-loads.  */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads" } */
+
+extern int strcmp (const char *, const char *);
+extern char *strcpy (char *, const char *);
+
+static struct
+{
+  char *b;
+  char *c;
+} d[] = {
+  {"0", "000000000000000"}, {"1", "111111111111111"},
+};
+
+void
+e (const char *b, char *c)
+{
+  int i;
+  for (i = 0; i < 1; ++i)
+    if (!strcmp (d[i].b, b))
+      strcpy (c, d[i].c);
+}
+
+/* { dg-final { scan-assembler-not ":lo12:" } } */

             reply	other threads:[~2017-01-11 16:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11 16:32 Kyrill Tkachov [this message]
2017-01-13 16:36 ` James Greenhalgh
2017-01-16 15:34   ` Kyrill Tkachov
2017-06-22 18:42     ` Yvan Roux
2017-06-27  9:17       ` Yvan Roux
2017-06-27 10:53       ` Wilco Dijkstra
2017-06-27 11:14         ` Yvan Roux
2017-07-03 10:48           ` Yvan Roux
2017-07-11 10:26             ` Yvan Roux
2017-08-04 13:50               ` 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=58765E2D.5030609@foss.arm.com \
    --to=kyrylo.tkachov@foss.arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=james.greenhalgh@arm.com \
    --cc=marcus.shawcroft@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).