public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] middle-end/100786 - constant folding from incompatible alias
Date: Thu, 20 Jan 2022 16:10:06 +0100 (CET)	[thread overview]
Message-ID: <p194o835-527-n76-r41p-oo3r3r44752@fhfr.qr> (raw)
In-Reply-To: <9p69r24-rs95-roq-7510-841399s88os@fhfr.qr>

On Thu, 20 Jan 2022, Richard Biener wrote:

> On Thu, 20 Jan 2022, Jakub Jelinek wrote:
> 
> > On Thu, Jan 20, 2022 at 02:58:21PM +0100, Richard Biener via Gcc-patches wrote:
> > > The following avoids us ICEing doing constant folding from variables
> > > with aliases of different types.  The formerly used fold_convert
> > > wasn't entirely correct even for the cases it handled and using
> > > a VIEW_CONVERT_EXPR avoids the ICE.  Reading from a larger alias
> > > will cause unfolded constants to appear but appearantly we handle
> > > that just "fine".
> > > 
> > >   b.0_1 = VIEW_CONVERT_EXPR<double>(1);
> > 
> > If they have the same sizes, why not, but doesn't int have
> > different size from double and isn't VCE defined only for same sizes?
> 
> Well yes, it's undefined.  IL wise we only constrain us for SSA
> operands, not constants.  But the whole testcase is undefined,
> and previously we'd happily accept a int -1 as a -1 long by
> sign-extending it.
> 
> I'm going to test an alternative patch tackling get_symbol_constant_value
> which is only used from CCP (which looks suffering from the same issue)
> and folding.

Like the following.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

From cc3f3c7428253c2326a00699f08bd89467b941f5 Mon Sep 17 00:00:00 2001
From: Richard Biener <rguenther@suse.de>
Date: Thu, 20 Jan 2022 14:25:51 +0100
Subject: [PATCH] middle-end/100786 - constant folding from incompatible alias
To: gcc-patches@gcc.gnu.org

The following avoids us ICEing doing constant folding from variables
with aliases of different types.  The issue appears both in
folding and CCP and FRE can do more fancy stuff to still constant
fold cases where the load is smaller than the initializer so
defer it to there.

2022-01-20  Richard Biener  <rguenther@suse.de>

	PR middle-end/100786
	* gimple-fold.cc (get_symbol_constant_value): Only return
	values of compatible type to the symbol.

	* gcc.dg/torture/pr100786.c: New testcase.
---
 gcc/gimple-fold.cc                      | 4 +++-
 gcc/testsuite/gcc.dg/torture/pr100786.c | 9 +++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr100786.c

diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 08d3cc214ff..3639aa20626 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -291,7 +291,9 @@ get_symbol_constant_value (tree sym)
       if (val)
 	{
 	  val = canonicalize_constructor_val (unshare_expr (val), sym);
-	  if (val && is_gimple_min_invariant (val))
+	  if (val
+	      && is_gimple_min_invariant (val)
+	      && useless_type_conversion_p (TREE_TYPE (sym), TREE_TYPE (val)))
 	    return val;
 	  else
 	    return NULL_TREE;
diff --git a/gcc/testsuite/gcc.dg/torture/pr100786.c b/gcc/testsuite/gcc.dg/torture/pr100786.c
new file mode 100644
index 00000000000..42f4e485593
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr100786.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+
+const double a = 0;
+extern int b __attribute__((alias("a")));
+void inc() { b++; }
+
+const int a2 = 0;
+extern double b2 __attribute__((alias("a2")));
+void inc2() { b2+=1; }
-- 
2.31.1


  reply	other threads:[~2022-01-20 15:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20 13:58 Richard Biener
2022-01-20 14:02 ` Jakub Jelinek
2022-01-20 14:21   ` Richard Biener
2022-01-20 15:10     ` Richard Biener [this message]
2022-03-26 16:54 FX
2022-03-28  6:34 ` 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=p194o835-527-n76-r41p-oo3r3r44752@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).