On Wed, Sep 21, 2022 at 9:52 AM Aldy Hernandez <al...@redhat.com> wrote: > > The reason the flags were uninitialized was because they were unused, > similarly for m_type. But you're right, it is icky and prone to bugs. > I just thought it was cheap to set_undefined by just flipping > m_kind=VR_UNDEFINED, but it smells like premature optimization. > > How about this?
LGTM > > Aldy > > On Wed, Sep 21, 2022 at 9:39 AM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > On Tue, Sep 20, 2022 at 8:23 PM Aldy Hernandez via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > > > > Undefined ranges have undefined NAN bits. We can't depend on them, > > > as they may contain garbage. > > > > Ick ;) Can you add a comment at least? > > > > > This patch returns false from > > > maybe_isnan() for undefined ranges (the empty set). > > > > > > gcc/ChangeLog: > > > > > > * value-range.h (frange::maybe_isnan): Return false for > > > undefined ranges. > > > --- > > > gcc/value-range.h | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/gcc/value-range.h b/gcc/value-range.h > > > index 7d5584a9294..325ed08f290 100644 > > > --- a/gcc/value-range.h > > > +++ b/gcc/value-range.h > > > @@ -1210,6 +1210,8 @@ frange::known_isinf () const > > > inline bool > > > frange::maybe_isnan () const > > > { > > > + if (undefined_p ()) > > > + return false; > > > return m_pos_nan || m_neg_nan; > > > } > > > > > > -- > > > 2.37.1 > > > > >