From: Aldy Hernandez <aldyh@redhat.com>
To: GCC patches <gcc-patches@gcc.gnu.org>
Cc: Andrew MacLeod <amacleod@redhat.com>, Aldy Hernandez <aldyh@redhat.com>
Subject: [PATCH] Initialize value in bit_value_unop.
Date: Tue, 25 Jul 2023 21:07:31 +0200 [thread overview]
Message-ID: <20230725190739.37779-3-aldyh@redhat.com> (raw)
In-Reply-To: <20230725190739.37779-1-aldyh@redhat.com>
bit_value_binop initializes VAL regardless of the final mask. It even
has a comment to that effect:
/* Ensure that VAL is initialized (to any value). */
However, bit_value_unop, which in theory shares the same API, does not.
This causes range-ops to choke on uninitialized VALs for some inputs to
ABS.
Instead of fixing the callers, it's cleaner to make bit_value_unop and
bit_value_binop consistent.
OK for trunk?
gcc/ChangeLog:
* tree-ssa-ccp.cc (bit_value_unop): Initialize val when appropriate.
---
gcc/tree-ssa-ccp.cc | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/tree-ssa-ccp.cc b/gcc/tree-ssa-ccp.cc
index 73fb7c11c64..15e65f16008 100644
--- a/gcc/tree-ssa-ccp.cc
+++ b/gcc/tree-ssa-ccp.cc
@@ -1359,7 +1359,10 @@ bit_value_unop (enum tree_code code, signop type_sgn, int type_precision,
case ABS_EXPR:
case ABSU_EXPR:
if (wi::sext (rmask, rtype_precision) == -1)
- *mask = -1;
+ {
+ *mask = -1;
+ *val = 0;
+ }
else if (wi::neg_p (rmask))
{
/* Result is either rval or -rval. */
@@ -1385,6 +1388,7 @@ bit_value_unop (enum tree_code code, signop type_sgn, int type_precision,
default:
*mask = -1;
+ *val = 0;
break;
}
}
--
2.41.0
next prev parent reply other threads:[~2023-07-25 19:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 19:07 [COMMITTED] Make some functions in CCP static Aldy Hernandez
2023-07-25 19:07 ` Aldy Hernandez [this message]
2023-07-26 8:19 ` [PATCH] Initialize value in bit_value_unop 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=20230725190739.37779-3-aldyh@redhat.com \
--to=aldyh@redhat.com \
--cc=amacleod@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).