public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] tree-optimization/110496 - TYPE_PRECISION issue with store-merging
Date: Fri, 30 Jun 2023 12:59:20 +0200 (CEST)	[thread overview]
Message-ID: <20230630105920.BA70D138F8@imap2.suse-dmz.suse.de> (raw)

When store-merging looks for bswap opportunities we also handle
BIT_FIELD_REFs where we verify the refed object is of scalar
type but we don't check for the result type we eventually use.
That's done later but after we eventually query TYPE_PRECISION.
The following re-orders this.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

	PR tree-optimization/110496
	* gimple-ssa-store-merging.cc (find_bswap_or_nop_1): Re-order
	verifying and TYPE_PRECISION query for the BIT_FIELD_REF case.

	* gcc.dg/pr110496.c: New testcase.
---
 gcc/gimple-ssa-store-merging.cc |  5 ++++-
 gcc/testsuite/gcc.dg/pr110496.c | 26 ++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr110496.c

diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 401496a9231..0d19b98ed73 100644
--- a/gcc/gimple-ssa-store-merging.cc
+++ b/gcc/gimple-ssa-store-merging.cc
@@ -650,10 +650,13 @@ find_bswap_or_nop_1 (gimple *stmt, struct symbolic_number *n, int limit)
 
 	  /* Convert.  */
 	  n->type = TREE_TYPE (rhs1);
+	  if (!verify_symbolic_number_p (n, stmt))
+	    return NULL;
+
 	  if (!n->base_addr)
 	    n->range = TYPE_PRECISION (n->type) / BITS_PER_UNIT;
 
-	  return verify_symbolic_number_p (n, stmt) ? stmt : NULL;
+	  return stmt;
 	}
 
       return NULL;
diff --git a/gcc/testsuite/gcc.dg/pr110496.c b/gcc/testsuite/gcc.dg/pr110496.c
new file mode 100644
index 00000000000..3c3d12fb532
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr110496.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+long contents, f_num;
+int decide();
+int f_MV0__x;
+void f() {
+  unsigned char *rptr;
+  unsigned char valbuf[6];
+  rptr = (unsigned char *)contents;
+  if (decide())
+    do {
+      __builtin_memcpy(valbuf, &f_MV0__x, sizeof(int));
+      (&valbuf[0])[4] = (&valbuf[0])[5] = 0;
+    } while (0);
+  else {
+    int MV0__x = f_num;
+    __builtin_memcpy(valbuf, &MV0__x, sizeof(int));
+    (&valbuf[0])[4] = (&valbuf[0])[5] = 0;
+  }
+  rptr[1] = valbuf[4];
+  rptr[2] = valbuf[5];
+  rptr[4] = valbuf[1];
+  rptr[5] = valbuf[2];
+  __builtin_memset(valbuf, 0, 8);
+}
-- 
2.35.3

                 reply	other threads:[~2023-06-30 10:59 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=20230630105920.BA70D138F8@imap2.suse-dmz.suse.de \
    --to=rguenther@suse.de \
    --cc=gcc-patches@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).