Re: [PATCH] Add support for floating point endpoints to frange.

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Aug 29, 2022 at 04:08:58PM +0200, Aldy Hernandez wrote:
> On Mon, Aug 29, 2022 at 3:55 PM Jakub Jelinek <jakub@redhat.com> wrote:
> >
> > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > > For convenience, singleton_p() returns false for a NAN.  IMO, it makes
> > > the implementation cleaner, but I'm not wed to the idea if someone
> > > objects.
> >
> > If singleton_p() is used to decide whether one can just replace a variable
> > with singleton range with a constant, then certainly.
> > If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and
> > NaNs have lots of different representations (the sign bit is ignored
> > except for stuff like copysign/signbit, there are qNaNs and sNaNs and
> > except for the single case how Inf is represented, all other values of the
> > mantissa mean different representations of NaN).  So, unless we track which
> > exact form of NaN can appear, NaN or any [x, x] range with NaN property
> 
> Ok that was more or less what I was thinking.  And no, we don't keep
> track of the type of NANs.
> 
> How does this look?
> 
> bool
> frange::singleton_p (tree *result) const
> {
>   if (m_kind == VR_RANGE && real_identical (&m_min, &m_max))
>     {
>       // If we're honoring signed zeros, fail because we don't know
>       // which zero we have.  This avoids propagating the wrong zero.
>       if (HONOR_SIGNED_ZEROS (m_type) && zero_p ())
>     return false;
> 
>       // Return false for any singleton that may be a NAN.
>       if (!get_nan ().no_p ())
>     return false;

Perhaps if (HONOR_NANS (m_type) && !get_nan ().no_p ()) instead?
Or do you ensure the nan property is never set for -ffinite-math-only?
> 
>       if (result)
>     *result = build_real (m_type, m_min);
>       return true;
>     }
>   return false;
> }

Otherwise LGTM.

	Jakub