frange is using some of the default vrange setters, some of which are
leaving the range in an undefined state.  We hadn't noticed this
because neither frange nor unsupported_range, both which use some of
the default implementation, weren't being used much.

We can never go wrong with setting VARYING ;-).

Will commit after tests complete.

gcc/ChangeLog:

        * value-range.cc (vrange::set): Set varying.
        (vrange::set_nonzero): Same.
        (vrange::set_zero): Same.
        (vrange::set_nonnegative): Same.
---
 gcc/value-range.cc | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index d056f7356e1..edd10bf5794 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -94,8 +94,9 @@ vrange::singleton_p (tree *) const
 }
 
 void
-vrange::set (tree, tree, value_range_kind)
+vrange::set (tree min, tree, value_range_kind)
 {
+  set_varying (TREE_TYPE (min));
 }
 
 tree
@@ -168,18 +169,21 @@ vrange::nonzero_p () const
 }
 
 void
-vrange::set_nonzero (tree)
+vrange::set_nonzero (tree type)
 {
+  set_varying (type);
 }
 
 void
-vrange::set_zero (tree)
+vrange::set_zero (tree type)
 {
+  set_varying (type);
 }
 
 void
-vrange::set_nonnegative (tree)
+vrange::set_nonnegative (tree type)
 {
+  set_varying (type);
 }
 
 bool
-- 
2.37.1

Reply via email to