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?
