OK, I'm good to go.

As the patch was getting rather large, I have split it into two parts.
The first is the core endpoints support to frange along with removal
of the +-INF markers (since they are no longer needed).  The second
part is the FP relational operators.  Splitting it up should help in
reviewing/improving the code for readers.  Also, it always helps
regression hunting to have smaller pieces ;-).

Retested on x86-64 Linux.

Pushed.




On Mon, Aug 29, 2022 at 4:42 PM Toon Moene <toon@moene.org> wrote:
>
> On 8/29/22 16:36, Aldy Hernandez wrote:
>
> > On Mon, Aug 29, 2022 at 4:30 PM Toon Moene <toon@moene.org> wrote:
> >>
> >> On 8/29/22 16:15, Aldy Hernandez wrote:
> >>
> >>> But even with -ffinite-math-only, is there any benefit to propagating
> >>> a known NAN?  For example:
> >>
> >> The original intent (in 2002) for the option -ffinite-math-only was for
> >> the optimizers to ignore all the various exceptions to common
> >> optimizations because they might not work correctly when presented with
> >> a NaN or an Inf.
> >>
> >> I do not know what the effect for floating point range information would
> >> be - offhand.
> >>
> >> But in the *spirit* of this option would be to ignore that the range
> >> [5.0, 5.0] would "also" contain NaN, for instance.
> >
> > Hmm, this is somewhat similar to what Jakub suggested.  Perhaps we
> > could categorically set !NAN for !HONOR_NANS at frange construction
> > time?
> >
> > For reference:
> > bool
> > HONOR_NANS (machine_mode m)
> > {
> >    return MODE_HAS_NANS (m) && !flag_finite_math_only;
> > }
> >
> > Thanks.
> > Aldy
> >
>
> Yep, I think that would do it.
>
> Thanks,
>
> --
> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
>