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