public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Matthew Malcomson <matmal01@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/vendors/ARM/heads/morello)] Fix mode assumptions in convert_memory_address
Date: Thu,  5 May 2022 12:09:23 +0000 (GMT)	[thread overview]
Message-ID: <20220505120923.C5D773856276@sourceware.org> (raw)

https://gcc.gnu.org/g:a4a587c96ec5b85fbd90793d7a2d8b4e65d9745d

commit a4a587c96ec5b85fbd90793d7a2d8b4e65d9745d
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Thu Mar 17 15:15:49 2022 +0000

    Fix mode assumptions in convert_memory_address
    
    convert_memory_address_addr_space_1 was making some dodgy assumptions
    about the modes of CONST_INTs.  We can skip those entirely for
    capabilities, which are never CONST_INTs.
    
    The testcase requires -fgimple support for &__MEM, which is already
    valid gimple but wasn't recognised by the parser.

Diff:
---
 gcc/c/c-typeck.c                                   |  3 +++
 gcc/explow.c                                       | 23 +++++++++++++++++++---
 .../aarch64/morello/hybrid-addr-expr-9.c           | 13 ++++++++++++
 3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 3cd39f6cf04..8bd7e286e93 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -4987,6 +4987,9 @@ lvalue_p (const_tree ref)
     case BIND_EXPR:
       return TREE_CODE (TREE_TYPE (ref)) == ARRAY_TYPE;
 
+    case MEM_REF:
+      return true;
+
     default:
       return false;
     }
diff --git a/gcc/explow.c b/gcc/explow.c
index e58e5923f2a..d7b04803e3f 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -374,9 +374,26 @@ convert_memory_address_addr_space_1 (scalar_addr_mode to_mode ATTRIBUTE_UNUSED,
 	      || GET_CODE (x) == SYMBOL_REF
 	      || GET_CODE (x) == CONST);
 
-  pointer_mode = unqualified_pointer_mode (as);
-  address_mode = unqualified_address_mode (as);
-  from_mode = to_mode == pointer_mode ? address_mode : pointer_mode;
+  /* ??? All this complication is because (a) X could be a CONST_INT
+     and (b) the caller doesn't tell us what mode X has.  So the assumption
+     appears to be that, if the caller has asked for a conversion, the current
+     CONST_INT must be the "other" mode from TO_MODE.  However, the early out
+     above proves that this assumption is false.
+
+     It would be good to clean this up and pass X's mode in all cases.
+     However, the current imprecision doesn't affect capability modes,
+     which are never CONST_INT.  So handle them specially for now.  */
+  if (CAPABILITY_MODE_P (GET_MODE (x)))
+    {
+      from_mode = as_a<scalar_addr_mode> (GET_MODE (x));
+      gcc_assert (targetm.valid_pointer_mode (from_mode));
+    }
+  else
+    {
+      pointer_mode = unqualified_pointer_mode (as);
+      address_mode = unqualified_address_mode (as);
+      from_mode = to_mode == pointer_mode ? address_mode : pointer_mode;
+    }
   /* Just assert that the input is as it should be  (X is a memory address in
      the previous mode).  */
   switch (GET_CODE (x))
diff --git a/gcc/testsuite/gcc.target/aarch64/morello/hybrid-addr-expr-9.c b/gcc/testsuite/gcc.target/aarch64/morello/hybrid-addr-expr-9.c
new file mode 100644
index 00000000000..7ebcd7f0f57
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/morello/hybrid-addr-expr-9.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fgimple" } */
+/* { dg-skip-if "" { *-*-* } { "-mabi=purecap" "-mfake-capability" } { "" } }  */
+
+int x;
+__GIMPLE int *foo(int i) {
+  int *__capability ptr;
+  int *res;
+
+  ptr = __CAP_ADDR x;
+  res = &__MEM<int> (ptr + 4);
+  return res;
+}


                 reply	other threads:[~2022-05-05 12:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220505120923.C5D773856276@sourceware.org \
    --to=matmal01@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /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).