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;
+}
next 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).