public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Richard Biener <rguenther@suse.de>
Subject: [PR 69355] Correct hole detection when total_scalarization fails
Date: Tue, 26 Jan 2016 17:21:00 -0000	[thread overview]
Message-ID: <20160126172131.GJ32511@virgil.suse.cz> (raw)

Hi,

PR 69355 has revealed that when SRA attempts total scalarization of an
aggregate but this fails because the user type-casts a scalar field
and stores into a it a smaller aggregate (and the scalar field is not
written to, whether directly or as a part of an aggregate store), the
pass can loose track of unscalarized data there.

I think that this can happen only when violating strict aliasing rules
but with -fno-strict-aliasing it should work.

Fixed thusly with the patch below (the condition is there to avoid
detecting padding after aggregate-fields in totally-scalarized
aggregates as unscalarized data).  Bootstrapped and tested on
x86_64-linux.  OK for trunk?  And the gcc-5 branch?

Thanks,

Martin


2016-01-26  Martin Jambor  <mjambor@suse.cz>

	PR tree-optimization/69355
	* tree-sra.c (analyze_access_subtree): Correct hole detection when
	total_scalarization fails.

testsuite/
	* gcc.dg/tree-ssa/pr69355.c: New test.

---
 gcc/testsuite/gcc.dg/tree-ssa/pr69355.c | 44 +++++++++++++++++++++++++++++++++
 gcc/tree-sra.c                          |  2 +-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr69355.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c b/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c
new file mode 100644
index 0000000..f515c21
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c
@@ -0,0 +1,44 @@
+/* { dg-do run } */
+/* { dg-options "-O -fno-strict-aliasing" } */
+
+struct S
+{
+  void *a;
+  long double b;
+};
+
+struct Z
+{
+  long long l;
+  short s;
+} __attribute__((packed));
+
+struct S __attribute__((noclone, noinline))
+foo (void *v, struct Z *z)
+{
+  struct S t;
+  t.a = v;
+  *(struct Z *) &t.b = *z;
+  return t;
+}
+
+struct Z gz;
+
+int
+main (int argc, char **argv)
+{
+  struct S s;
+
+  if (sizeof (long double) < sizeof (struct Z))
+    return 0;
+
+  gz.l = 0xbeef;
+  gz.s = 0xab;
+
+  s = foo ((void *) 0, &gz);
+
+  if ((((struct Z *) &s.b)->l != gz.l)
+      || (((struct Z *) &s.b)->s != gz.s))
+    __builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 740542f..b0e737a 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2421,7 +2421,7 @@ analyze_access_subtree (struct access *root, struct access *parent,
 
       if (covered_to < limit)
 	hole = true;
-      if (scalar)
+      if (scalar || !allow_replacements)
 	root->grp_total_scalarization = 0;
     }
 
-- 
2.7.0

             reply	other threads:[~2016-01-26 17:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 17:21 Martin Jambor [this message]
2016-01-27  8:37 ` Richard Biener

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=20160126172131.GJ32511@virgil.suse.cz \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).