public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: gcc-patches@gcc.gnu.org
Subject: [RFA] Fix pr67830, another type narrowing problem
Date: Fri, 23 Oct 2015 06:32:00 -0000	[thread overview]
Message-ID: <5629D22D.2030704@redhat.com> (raw)

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

/* This is another case of narrowing, specifically when there's an outer
    BIT_AND_EXPR which masks off bits outside the type of the innermost
    operands.   Like the previous case we have to convert the operands
    to unsigned types to avoid introducing undefined behaviour for the
    arithmetic operation.  */


Essentially tthat pattern in match.pd is trying to catch cases where we 
widen two operands, do some arithmetic, then mask off all the bits that 
were outside the width of the original operands.

In this case the mask is -2 and the inner operands are unsigned 
characters that get widened to signed integers.

Obviously with a mask of -2, the we are _not_ masking off bits outside 
the width of the original operands.  So even if those operands are 
marked with TYPE_OVERFLOW_WRAPS, this optimization must not be applied.

What's so obviously missing here is actually checking the mask.

(mask & (-1UL << TYPE_PRECISION (original operand))) == 0

Is a nice simple way to know if there's any bits outside the precision 
of the original operand  in the mask.

Bootstrapped and regression tested on x86_64-linux-gnu.  OK for the trunk?

Thanks,
jeff

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 1140 bytes --]

diff --git a/gcc/match.pd b/gcc/match.pd
index b399786..46188cb 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2619,8 +2619,8 @@ along with GCC; see the file COPYING3.  If not see
        && types_match (@0, @1)
        && (tree_int_cst_min_precision (@4, TYPE_SIGN (TREE_TYPE (@0)))
 	   <= TYPE_PRECISION (TREE_TYPE (@0)))
-       && (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
-	   || tree_int_cst_sgn (@4) >= 0))
+       && (TREE_INT_CST_LOW (@4)
+	   & (HOST_WIDE_INT_M1U << TYPE_PRECISION (TREE_TYPE (@0)))) == 0)
    (if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
     (with { tree ntype = TREE_TYPE (@0); }
      (convert (bit_and (op @0 @1) (convert:ntype @4))))
diff --git a/gcc/testsuite/gcc.dg/pr67830.c b/gcc/testsuite/gcc.dg/pr67830.c
new file mode 100644
index 0000000..9bfb0c0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr67830.c
@@ -0,0 +1,22 @@
+/* PR tree-optimization/67830 */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+int a, b, *g, h;
+unsigned char c, d;
+
+int
+main ()
+{
+  int f, e = -2;
+  b = e;
+  g = &b;
+  h = c = a + 1;
+  f = d - h;
+  *g &= f;
+
+  if (b != -2)
+    __builtin_abort ();
+
+  return 0;
+}

             reply	other threads:[~2015-10-23  6:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23  6:32 Jeff Law [this message]
2015-10-23  9:22 ` Richard Biener
2015-10-23 19:24   ` Jeff Law

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=5629D22D.2030704@redhat.com \
    --to=law@redhat.com \
    --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).