https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125475
Bug ID: 125475
Summary: tree_expr_nonnegative_p and its usage in the ranger is
a mess
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
So Looking into fixing up tree_expr_nonnegative_p and maybe trying to use the
ranger to do the same thing. Basically I am trying to remove the recusiveness
nature of tree_expr_nonnegative_p for SSA names.
BUT it turns out tree_expr_nonnegative_p is called from ranger via
fold_using_range::fold_stmt:
```
// If the result is varying, check for basic nonnegativeness.
// Specifically this helps for now with strict enum in cases like
// g++.dg/warn/pr33738.C.
if (res && r.varying_p () && INTEGRAL_TYPE_P (r.type ())
&& gimple_stmt_nonnegative_p (s))
r.set_nonnegative (r.type ());
```
So if we do:
```
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 352083e146b..e53b122c7cd 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14674,6 +14674,14 @@ tree_single_nonnegative_p (tree t, int depth)
return RECURSE (TREE_OPERAND (t, 1)) && RECURSE (TREE_OPERAND (t, 2));
case SSA_NAME:
+ if (INTEGRAL_TYPE_P (TREE_TYPE (t)))
+ {
+ int_range_max r;
+ get_range_query (cfun)->range_of_expr (r, t);
+ if (!r.undefined_p () && !r.varying_p()
+ && r.nonnegative_p ())
+ return true;
+ }
/* Limit the depth of recursion to avoid quadratic behavior.
This is expected to catch almost all occurrences in practice.
If this code misses important cases that unbounded recursion
```
This goes into an infinite loop.
I am not sure if the code in fold_using_range::fold_stmt is needed any more. It
was added with r13-3508-ga87819b8f1b890 .
So the question becomes why can't the ranger figure out this is nonnegative on
its own?
