From: Andrew MacLeod <amacleod@redhat.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>
Cc: "hernandez, aldy" <aldyh@redhat.com>
Subject: [PATCH] Audit op1_range and op2_range for undefined LHS.
Date: Thu, 29 Sep 2022 18:35:09 -0400 [thread overview]
Message-ID: <16763009-abeb-5785-80fc-40cd755fef0c@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
If the LHS is undefined, GORI should not proceed further. There are a
few places where this happens, and a few potential traps. Most haven't
been an issue up until now, but forthcoming changes tend to cause them
to trigger more often.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
[-- Attachment #2: 0002-Audit-op1_range-and-op2_range-for-undefined-LHS.patch --]
[-- Type: text/x-patch, Size: 5343 bytes --]
From beb135aaabac4771a405b8d41ad37285ee6f872e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod <amacleod@redhat.com>
Date: Tue, 27 Sep 2022 19:12:06 -0400
Subject: [PATCH 2/6] Audit op1_range and op2_range for undefined LHS.
If the LHS is undefined, GORI should cease looking. There are numerous
places where this happens, and a few potential traps.
* range-op.cc (operator_minus::op2_range): Check for undefined.
(operator_mult::op1_range): Ditto.
(operator_exact_divide::op1_range): Ditto.
(operator_lshift::op1_range): Ditto.
(operator_rshift::op1_range): Ditto.
(operator_cast::op1_range): Ditto.
(operator_bitwise_and::op1_range): Ditto.
(operator_bitwise_or::op1_range): Ditto.
(operator_trunc_mod::op1_range): Ditto.
(operator_trunc_mod::op2_range): Ditto.
(operator_bitwise_not::op1_range): Ditto.
(pointer_or_operator::op1_range): Ditto.
(range_op_handler::op1_range): Ditto.
(range_op_handler::op2_range): Ditto.
---
gcc/range-op.cc | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 072ebd32109..9bb04c361d0 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -1481,6 +1481,8 @@ operator_minus::op2_range (irange &r, tree type,
const irange &op1,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
return fold_range (r, type, op1, lhs);
}
@@ -1650,6 +1652,8 @@ operator_mult::op1_range (irange &r, tree type,
relation_kind rel ATTRIBUTE_UNUSED) const
{
tree offset;
+ if (lhs.undefined_p ())
+ return false;
// We can't solve 0 = OP1 * N by dividing by N with a wrapping type.
// For example: For 0 = OP1 * 2, OP1 could be 0, or MAXINT, whereas
@@ -1902,6 +1906,8 @@ operator_exact_divide::op1_range (irange &r, tree type,
const irange &op2,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
tree offset;
// [2, 4] = op1 / [3,3] since its exact divide, no need to worry about
// remainders in the endpoints, so op1 = [2,4] * [3,3] = [6,12].
@@ -2111,6 +2117,8 @@ operator_lshift::op1_range (irange &r,
const irange &op2,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
tree shift_amount;
if (!lhs.contains_p (build_zero_cst (type)))
@@ -2183,6 +2191,8 @@ operator_rshift::op1_range (irange &r,
relation_kind rel ATTRIBUTE_UNUSED) const
{
tree shift;
+ if (lhs.undefined_p ())
+ return false;
if (op2.singleton_p (&shift))
{
// Ignore nonsensical shifts.
@@ -2401,6 +2411,8 @@ operator_cast::op1_range (irange &r, tree type,
const irange &op2,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
tree lhs_type = lhs.type ();
gcc_checking_assert (types_compatible_p (op2.type(), type));
@@ -2936,6 +2948,8 @@ operator_bitwise_and::op1_range (irange &r, tree type,
const irange &op2,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
if (types_compatible_p (type, boolean_type_node))
return op_logical_and.op1_range (r, type, lhs, op2);
@@ -3112,6 +3126,8 @@ operator_bitwise_or::op1_range (irange &r, tree type,
const irange &op2,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
// If this is really a logical wi_fold, call that.
if (types_compatible_p (type, boolean_type_node))
return op_logical_or.op1_range (r, type, lhs, op2);
@@ -3361,6 +3377,8 @@ operator_trunc_mod::op1_range (irange &r, tree type,
const irange &,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
// PR 91029.
signop sign = TYPE_SIGN (type);
unsigned prec = TYPE_PRECISION (type);
@@ -3385,6 +3403,8 @@ operator_trunc_mod::op2_range (irange &r, tree type,
const irange &,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
// PR 91029.
signop sign = TYPE_SIGN (type);
unsigned prec = TYPE_PRECISION (type);
@@ -3513,6 +3533,8 @@ operator_bitwise_not::op1_range (irange &r, tree type,
const irange &op2,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
if (types_compatible_p (type, boolean_type_node))
return op_logical_not.op1_range (r, type, lhs, op2);
@@ -3999,6 +4021,8 @@ pointer_or_operator::op1_range (irange &r, tree type,
const irange &op2 ATTRIBUTE_UNUSED,
relation_kind rel ATTRIBUTE_UNUSED) const
{
+ if (lhs.undefined_p ())
+ return false;
if (lhs.zero_p ())
{
tree zero = build_zero_cst (type);
@@ -4230,6 +4254,9 @@ range_op_handler::op1_range (vrange &r, tree type,
relation_kind rel) const
{
gcc_checking_assert (m_valid);
+
+ if (lhs.undefined_p ())
+ return false;
if (m_int)
return m_int->op1_range (as_a <irange> (r), type,
as_a <irange> (lhs),
@@ -4251,6 +4278,8 @@ range_op_handler::op2_range (vrange &r, tree type,
relation_kind rel) const
{
gcc_checking_assert (m_valid);
+ if (lhs.undefined_p ())
+ return false;
if (m_int)
return m_int->op2_range (as_a <irange> (r), type,
as_a <irange> (lhs),
--
2.37.3
reply other threads:[~2022-09-29 22:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=16763009-abeb-5785-80fc-40cd755fef0c@redhat.com \
--to=amacleod@redhat.com \
--cc=aldyh@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).