On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote: > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > > > > Intersecting two ranges where one is a NAN is keeping the sign bit of > > > the NAN range. This is not correct as the sign bits may not match. > > > > > > I think the only time we're absolutely sure about the intersection of > > > a NAN and something else, is when both are a NAN with exactly the same > > > properties (sign bit). If we're intersecting two NANs of differing > > > sign, we can decide later whether that's undefined or just a NAN with > > > no known sign. For now I've done the latter. > > > > > > I'm still mentally working on intersections involving NANs, especially > > > if we want to keep track of signbits. For now, let's be extra careful > > > and only do things we're absolutely sure about. > > > > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5] > > > with the posibility of NAN, to a NAN, but I'm not 100% sure. > > > > The intersection of [NAN, NAN] and [3, 5] is empty. The intersection > > of [NAN, NAN] and VARYING is [NAN, NAN]. > > I think [3.0, 5.0] printed that way currently means U maybe NAN, > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
Right. I don't print any of the "maybe" properties, just if they're definitely set or definitely clear. I'm open to suggestions as to how to display them. Perhaps NAN, !NAN, ?NAN. I'm mostly worried about removing a NAN from the IL that was going to signal, or some such. While I agree with you Richard, I just want to make real sure, because getting something wrong in the frange or range-ops bowels means the problem becomes pervasive to all of ranger ...and threader...and loop ch...and vrp, etc etc. I just want to take more time to test things. I promise it won't stay varying too long. Aldy
