public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>,
	"MacLeod, Andrew" <amacleod@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
	GCC patches <gcc-patches@gcc.gnu.org>
Subject: Re: [COMMITTED] Be even more conservative in intersection of NANs.
Date: Mon, 5 Sep 2022 11:11:57 +0200	[thread overview]
Message-ID: <CAGm3qMU0KAqmudP9orh4BSYbDxjqSk=osR=R=yiHRCgyn9k3Cg@mail.gmail.com> (raw)
In-Reply-To: <YxW7/gY8UgLcy2C6@tucnak>

On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> > >
> > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > the NAN range.  This is not correct as the sign bits may not match.
> > >
> > > I think the only time we're absolutely sure about the intersection of
> > > a NAN and something else, is when both are a NAN with exactly the same
> > > properties (sign bit).  If we're intersecting two NANs of differing
> > > sign, we can decide later whether that's undefined or just a NAN with
> > > no known sign.  For now I've done the latter.
> > >
> > > I'm still mentally working on intersections involving NANs, especially
> > > if we want to keep track of signbits.  For now, let's be extra careful
> > > and only do things we're absolutely sure about.
> > >
> > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> >
> > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > of [NAN, NAN] and VARYING is [NAN, NAN].
>
> I think [3.0, 5.0] printed that way currently means U maybe NAN,
> it would be [3.0, 5.0] !NAN if it was known not to be NAN.

Right.  I don't print any of the "maybe" properties, just if they're
definitely set or definitely clear.  I'm open to suggestions as to how
to display them.  Perhaps NAN, !NAN, ?NAN.

I'm mostly worried about removing a NAN from the IL that was going to
signal, or some such.  While I agree with you Richard, I just want to
make real sure, because getting something wrong in the frange or
range-ops bowels means the problem becomes pervasive to all of ranger
...and threader...and loop ch...and vrp, etc etc.  I just want to take
more time to test things.  I promise it won't stay varying too long.

Aldy


  reply	other threads:[~2022-09-05  9:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05  6:23 Aldy Hernandez
2022-09-05  9:00 ` Richard Biener
2022-09-05  9:06   ` Jakub Jelinek
2022-09-05  9:11     ` Aldy Hernandez [this message]
2022-09-05  9:18       ` Richard Biener
2022-09-05  9:41         ` Aldy Hernandez
2022-09-05  9:53           ` Richard Biener
2022-09-05 10:24             ` Aldy Hernandez
2022-09-05 10:38               ` Richard Biener
2022-09-05 11:45                 ` Aldy Hernandez
2022-09-05 12:16                   ` Richard Biener
2022-09-06  7:21                     ` Aldy Hernandez
2022-09-06  9:09                       ` Richard Biener
2022-09-06 10:26                         ` Aldy Hernandez
2022-09-05  9:13     ` Richard Biener
2022-09-05  9:28       ` Aldy Hernandez
2022-09-05  9:41         ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGm3qMU0KAqmudP9orh4BSYbDxjqSk=osR=R=yiHRCgyn9k3Cg@mail.gmail.com' \
    --to=aldyh@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).