[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608

--- Comment #24 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #21)
> (In reply to Richard Biener from comment #13)
> 
> > Yes, the fact that ranger doesn't operate as a usual propagator with a
> > lattice
> > makes things very difficult here.  Note that my comment referred to code
> > optimality, not correctness.
> > 
> > > It really looks like the problem here is DCE (and the gimplifier as you
> > > point out in comment #2), which is removing a needed statement.  Can't this
> > > be fixed there?
> > 
> > Sure it can, but the expense is that we'd do constant folding all the way
> > down and not remove dead code which will result in _tons_ of unnecessary
> > constant pool entries and loads.
> > 
> 
> I think I'm missing something, or not understanding what you are saying.
> 
> Why is the propagation or lack of lattice a problem?   Its DCE that is
> removing that potentially trapping stmt because its no longer used in the
> IL?  THe change would be to not kill off dead statements that may trap?  I
> guess this may leave a bunch of feeding statements that are not dead.. but I
> fail to see how thats different than not propagating and then not being able
> to delete those stmts either?  
> 
> 
> > The issue is also that -ftrapping-math is default on so we'd have to
> > do this by default.  Ugh.
> > 
> > Note that the constant folding routines generally refrain from folding
> > when that loses exceptions, it's just ranger when producing singleton
> > ranges and propagating from them that doesn't adhere to that implicit rule.
> 
> I'm also not sure what this means.  I don't think ranger itself propagates
> singleton constants.. VRP is still using the substitute_and_fold engine, so
> any folding/propagation is still going through the same mechanisms we always
> did when a singleton result is produced.  We just produce more of them now,
> especially with floats.  I don't think ranger is doing anything different
> than VRP ever did regarding propagation.   Its possible GCCs infrastructure
> for dealing with float propagation isn't mature enough perhaps?

Right, ranger isn't propagating anything.  It's the substitute_and_fold engine,
as it always has, but only if value_of_expr() is non-NULL.  Currently this
function will only return non-NULL for singletons:

tree
range_query::value_of_expr (tree expr, gimple *stmt)
{
  tree t;

  if (!Value_Range::supports_type_p (TREE_TYPE (expr)))
    return NULL_TREE;

  Value_Range r (TREE_TYPE (expr));

  if (range_of_expr (r, expr, stmt))
    {
      // A constant used in an unreachable block oftens returns as UNDEFINED.
      // If the result is undefined, check the global value for a constant.
      if (r.undefined_p ())
        range_of_expr (r, expr);
      if (r.singleton_p (&t))
        return t;
    }
  return NULL_TREE;
}