| Message ID | 20220920182223.2019637-1-aldyh@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [COMMITTED] frange::maybe_isnan() should return FALSE for undefined ranges. | expand |
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 >
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? Aldy On Wed, Sep 21, 2022 at 9:39 AM Richard Biener <richard.guenther@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 > > >
On Wed, Sep 21, 2022 at 9:52 AM Aldy Hernandez <aldyh@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.guenther@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 > > > > >
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; }