On Tue, Sep 06, 2022 at 09:49:55AM +0200, Aldy Hernandez wrote:
> On Tue, Sep 6, 2022 at 9:44 AM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Tue, Sep 06, 2022 at 09:40:59AM +0200, Aldy Hernandez wrote:
> > > if (x <= Inf)
> >
> > This will be [-Inf, Inf] !NAN on the true side and
> > NAN (either sign) on the false side indeed.
> >
> > > if (x < -Inf)
> >
> > will be NAN (either sign) on the true side and
> > [-Inf, Inf] !NAN on the false side.
>
> Sweet, that's exactly what I thought, thus the patch.
>
> Furthermore, for !HONOR_NANS I would expect the NAN sides above to be
> UNDEFINED/unreachable. That is, the false side of x <= Inf when
> !HONOR_NANS is unreachable.
In practice, there is no real format that has NaNs and doesn't have Infs
or vice versa and similarly we have just one switch to cover both Infinities
and NaNs, so either both are supported, or neither of them, or both
are supported but neither of them should appear in a valid program
(-ffinite-math-only on most floating point formats).
So the answer in that case is a little bit fuzzy because one shouldn't
compare against infinity in that case (or for !MODE_HAS_INFINITIES even
can't). But sure, if NaNs aren't possible or can't appear and you compare
x <= Largest_possible_float, then it is always true and so UNDEFINED on the
false edge.
Jakub
