[Bug tree-optimization/24021] VRP does not work with floating points

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

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

--- Comment #23 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #22)
> > This doesn't take flag_rounding_math or not always exactly precise floating
> > point computations into account.
> > It is also missing real_convert after real_arithmetics that performs at least
> > some of the rounding (and perhaps the inexact return value from
> > real_arithmetic
> > should be taken into account).
> > Without flag_rounding_math and on non-MODE_COMPOSITE_P the basic arithmetics
> > will be probably exact most of the time, except perhaps for denormals which
> > are
> > sometimes flushed to zero.  But as soon as one jumps to even sqrt and other
> > math functions, one needs to allow some epsilon up for upper bound and down
> > for lower bound, similarly for the basic ops with inexact and
> > flag_rounding_math.
> > For MODE_COMPOSITE_P, our emulation doesn't match what is done at runtime,
> > so we need to be more forgiving.
> 
> Definitely.  I'm pretty sure there's even more stuff I'm missing :).  We're
> only providing the core infrastructure-- the ability for ranger / vrp to
> handle basic floats.  We're hoping some float savvy hacker can fill in the
> rest.
> 
> The above does handle open and closed internals, though.  So it should be
> able to handle (5.0, 10.0] + [1.0, 1.0] if I understand correctly.  But I
> don't pretend to remotely know anything about floats.  I'm hoping the
> range-op entries can be implemented by a floating expert.
> 
> A bare bones implementation would provide relops, and maybe ?? singleton
> floats ([1.23, 1.23]).

Or...we could just use const_binop() instead of calling real_arithmetic
directly.  Wouldn't that handle all the cases you mention?