https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #22 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > 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]).
