[COMMITTED] PR tree-optimization/111009 - Fix range-ops operator_addr.
Checks
Commit Message
operator_addr was simply calling fold_range() to implement op1_range,
but it turns out op1_range needs to be more restrictive.
take for example from the PR :
_13 = &dso->maj
when folding, getting a value of 0 for op1 means dso->maj resolved to a
value of [0,0]. fold_using_range::range_of_address will have processed
the symbolics, or at least we know that op1 is 0. Likewise if it is
non-zero, we can also conclude the LHS is non-zero.
however, when working from the LHS, we cannot make the same
conclusions. GORI has no concept of symblics, so knowing the expressions is
[0,0] = & <unknown>
we cannot conclude the op1 is also 0.. in particular &dso->maj wouldnt
be unless dso was zero and maj was also a zero offset.
Likewise if the LHS is [1,1] we cant be sure op1 is nonzero unless we
know the type cannot wrap.
This patch simply implements op1_range with these rules instead of
calling fold_range.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From dc48d1d1d4458773f89f21b2f019f66ddf88f2e5 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod <amacleod@redhat.com>
Date: Thu, 17 Aug 2023 11:13:14 -0400
Subject: [PATCH] Fix range-ops operator_addr.
Lack of symbolic information prevents op1_range from beig able to draw
the same conclusions as fold_range can.
PR tree-optimization/111009
gcc/
* range-op.cc (operator_addr_expr::op1_range): Be more restrictive.
gcc/testsuite/
* gcc.dg/pr111009.c: New.
---
gcc/range-op.cc | 12 ++++++++++-
gcc/testsuite/gcc.dg/pr111009.c | 38 +++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/pr111009.c
@@ -4325,7 +4325,17 @@ operator_addr_expr::op1_range (irange &r, tree type,
const irange &op2,
relation_trio) const
{
- return operator_addr_expr::fold_range (r, type, lhs, op2);
+ if (empty_range_varying (r, type, lhs, op2))
+ return true;
+
+ // Return a non-null pointer of the LHS type (passed in op2), but only
+ // if we cant overflow, eitherwise a no-zero offset could wrap to zero.
+ // See PR 111009.
+ if (!contains_zero_p (lhs) && TYPE_OVERFLOW_UNDEFINED (type))
+ r = range_nonzero (type);
+ else
+ r.set_varying (type);
+ return true;
}
// Initialize any integral operators to the primary table
new file mode 100644
@@ -0,0 +1,38 @@
+/* PR tree-optimization/111009 */
+/* { dg-do run } */
+/* { dg-options "-O3 -fno-strict-overflow" } */
+
+struct dso {
+ struct dso * next;
+ int maj;
+};
+
+__attribute__((noipa)) static void __dso_id__cmp_(void) {}
+
+__attribute__((noipa))
+static int bug(struct dso * d, struct dso *dso)
+{
+ struct dso **p = &d;
+ struct dso *curr = 0;
+
+ while (*p) {
+ curr = *p;
+ // prevent null deref below
+ if (!dso) return 1;
+ if (dso == curr) return 1;
+
+ int *a = &dso->maj;
+ // null deref
+ if (!(a && *a)) __dso_id__cmp_();
+
+ p = &curr->next;
+ }
+ return 0;
+}
+
+__attribute__((noipa))
+int main(void) {
+ struct dso d = { 0, 0, };
+ bug(&d, 0);
+}
+