Re: RFA: don't try to compare IEEE NaN's

[Fernando Nasser <fnasser@redhat.com>]

Michael Snyder wrote:
> 
> Jim Blandy wrote:
> >
> > Eli Zaretskii <eliz@is.elta.co.il> writes:
> > > My assumption was that whoever wrote the test wanted to see that GDB
> > > doesn't lose bits due to all kinds of conversions that are going under
> > > the hood.  If that is true, you want to make sure the value you work with
> > > has the same bit pattern you wanted it to have.  If not, you don't really
> > > know what you are testing here; for example, imagine an (absurdly
> > > unrealistic) case that the compiler turns your literal constant into an
> > > all-zero bit pattern, or into a NaN.  Then you are back to square
> > > one.
> >
> > What you're saying is that, between this:
> >
> >         union {
> >           float f;
> >           char bytes[80];
> >         } u;
> >
> >         for (i = 0; i < 80; i++)
> >           u.bytes[i] = something interesting;
> >
> > and this:
> >
> >         u.f = 2.7182818284590452354;
> >
> > that you're more concerned that the latter will put a NaN in u.f than
> > the former.  When, in fact, the exact problem I'm trying to fix is
> > that someone's first shot at the former strategy produced a NaN.
> 
> "Someone" is me.  I of course knew that FFFFFFFF would be a NaN --
> I just didn't know that NaN could not be compared to itself on
> some platforms.  BTW, the reason for using a union as I did,
> rather than individual char, short, int etc. variables, was to
> make sure that the known bit pattern was actually larger than
> the type being tested -- so that we would know if, for instance,
> GDB was testing more bits than it should.

It makes sense.  It may still be possible to do this and still fix the
least significant bits to be a valid FP number.  It could be done before
calling the "float" and again before calling the "double" tests.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9