This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: don't try to compare IEEE NaN's
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