From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Michael Snyder Cc: Jim Blandy , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: RFA: don't try to compare IEEE NaN's Date: Wed, 06 Jun 2001 11:04:00 -0000 Message-id: <3B1E6FFE.AF13DD36@redhat.com> References: <3B1E6E7A.CEBC4116@cygnus.com> X-SW-Source: 2001-06/msg00084.html Michael Snyder wrote: > > Jim Blandy wrote: > > > > Eli Zaretskii 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