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

[Michael Snyder <msnyder@cygnus.com>]

Fernando Nasser wrote:
> 
> 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.

Or we could separate the fp test loads from the integer ones.
We could even separate the float test load from the double --
just so long as the float test load is bigger than a float.