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

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

[Jim Blandy]

2001-06-05  Jim Blandy  <jimb@redhat.com>

	* gdb.base/return2.exp (main): Use values to test float and double
	returns that are not NaN's, to avoid being confused by IEEE
	comparison rules.

Index: gdb/testsuite/gdb.base/return2.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/return2.c,v
retrieving revision 1.2
diff -c -r1.2 return2.c
*** gdb/testsuite/gdb.base/return2.c	2000/12/20 14:34:27	1.2
--- gdb/testsuite/gdb.base/return2.c	2001/06/06 03:39:25
***************
*** 84,91 ****
    int_resultval       = int_func ();		/* short_checkpoint */
    long_resultval      = long_func ();		/* int_checkpoint */
    long_long_resultval = long_long_func ();	/* long_checkpoint */
!   float_resultval     = float_func ();		/* long_long_checkpoint */
!   double_resultval    = double_func ();		/* float_checkpoint */
    main_test = 1;				/* double_checkpoint */
    return 0;
  }
--- 84,110 ----
    int_resultval       = int_func ();		/* short_checkpoint */
    long_resultval      = long_func ();		/* int_checkpoint */
    long_long_resultval = long_long_func ();	/* long_checkpoint */
! 
!   /* On machines using IEEE floating point, the test pattern of all
!      1-bits established above turns out to be a floating-point NaN
!      ("Not a Number").  According to the IEEE rules, NaN's aren't even
!      equal to themselves.  This can lead to stupid conversations with
!      GDB like:
! 
!        (gdb) p testval.float_testval == testval.float_testval
!        $7 = 0
!        (gdb)
! 
!      This is the correct answer, but it's not the sort of thing
!      return2.exp wants to see.  So to make things work the way they
!      ought, we'll set aside the `union' cleverness and initialize the
!      test values explicitly here.  These values have interesting bits
!      throughout the value, so we'll still detect truncated values.  */
! 
!   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
!   float_resultval     = float_func ();		
!   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
!   double_resultval    = double_func ();		
    main_test = 1;				/* double_checkpoint */
    return 0;
  }

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

[Eli Zaretskii]

> From: Jim Blandy <jimb@zwingli.cygnus.com>
> Date: Tue,  5 Jun 2001 22:41:45 -0500 (EST)
> 
> !   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
> !   float_resultval     = float_func ();		
> !   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
> !   double_resultval    = double_func ();		

I think it is better to initialize the integral members of the union
with an explicit bit pattern, just not a pattern which gets
interpreted as a NaN of an Inf.  With initialization such as above,
you risk losing due to subtleties of compile-time conversion of a
literal constant to a floating-point value.  This is a GDB test suite,
so we are not interested in testing the compiler.

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

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> > From: Jim Blandy <jimb@zwingli.cygnus.com>
> > Date: Tue,  5 Jun 2001 22:41:45 -0500 (EST)
> >
> > !   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
> > !   float_resultval     = float_func ();
> > !   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
> > !   double_resultval    = double_func ();
> 
> I think it is better to initialize the integral members of the union
> with an explicit bit pattern, just not a pattern which gets
> interpreted as a NaN of an Inf.  With initialization such as above,
> you risk losing due to subtleties of compile-time conversion of a
> literal constant to a floating-point value.  This is a GDB test suite,
> so we are not interested in testing the compiler.

This is a good point.  But we will need a different bit pattern for
float and double.  On the other hand, this way we test that the
constants are being converted correctly :-)  (yes, I know this is not
the objective of the test).

Note that we already use constant literals everywhere.  A recent patch
(well, not so recent) fixed the value of one of those so it would not be
truncated (and so result in a different internal value).

Anyway, the thing is so broken now that we cannot just leave as it is. 
Suggestion (with patches) for an improvement to this test are welcome. 

Cheers,
Fernando

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

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

[Jim Blandy]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> 
> > From: Jim Blandy <jimb@zwingli.cygnus.com>
> > Date: Tue,  5 Jun 2001 22:41:45 -0500 (EST)
> > 
> > !   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
> > !   float_resultval     = float_func ();		
> > !   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
> > !   double_resultval    = double_func ();		
> 
> I think it is better to initialize the integral members of the union
> with an explicit bit pattern, just not a pattern which gets
> interpreted as a NaN of an Inf.  With initialization such as above,
> you risk losing due to subtleties of compile-time conversion of a
> literal constant to a floating-point value.  This is a GDB test suite,
> so we are not interested in testing the compiler.

I'm not sure what you mean.  Once the test has assigned a value to
testval.float_testval, we only use that variable.  The compile-time
conversion happens exactly once, and then we always use the result of
that conversion.

I guess I need the problem explained to me in more detail.

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

[Eli Zaretskii]

On 6 Jun 2001, Jim Blandy wrote:

> > I think it is better to initialize the integral members of the union
> > with an explicit bit pattern, just not a pattern which gets
> > interpreted as a NaN or an Inf.  With initialization such as above,
> > you risk losing due to subtleties of compile-time conversion of a
> > literal constant to a floating-point value.  This is a GDB test suite,
> > so we are not interested in testing the compiler.
> 
> I'm not sure what you mean.  Once the test has assigned a value to
> testval.float_testval, we only use that variable.  The compile-time
> conversion happens exactly once, and then we always use the result of
> that conversion.

Let's begin by asking why do you at all set the members of the union to 
specific values?  Why not initialize them to zero, or even leave them at 
some random garbage they pick up from the stack?

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.

The only way to make sure you get the bit patterns you wanted is to 
initialize the integral members of the union with those bit patterns.  
You just want them to be different from a NaN or an Inf, because they 
cause trouble in comparisons.

Am I making any sense?

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

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> On 6 Jun 2001, Jim Blandy wrote:
> 
> > > I think it is better to initialize the integral members of the union
> > > with an explicit bit pattern, just not a pattern which gets
> > > interpreted as a NaN or an Inf.  With initialization such as above,
> > > you risk losing due to subtleties of compile-time conversion of a
> > > literal constant to a floating-point value.  This is a GDB test suite,
> > > so we are not interested in testing the compiler.
> >
> > I'm not sure what you mean.  Once the test has assigned a value to
> > testval.float_testval, we only use that variable.  The compile-time
> > conversion happens exactly once, and then we always use the result of
> > that conversion.
> 
> Let's begin by asking why do you at all set the members of the union to
> specific values?  Why not initialize them to zero, or even leave them at
> some random garbage they pick up from the stack?
> 
> 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.
> 
> The only way to make sure you get the bit patterns you wanted is to
> initialize the integral members of the union with those bit patterns.
> You just want them to be different from a NaN or an Inf, because they
> cause trouble in comparisons.
> 
> Am I making any sense?

I believe there will be many failures before that happen.

But, yes, loading the variables with known bit patterns would be immune
to that.  On the other hand, what would be the bit  pattern?  If we use
the IEEE one it may break in systems that do not use IEEE.


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

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

[Jim Blandy]

Fernando Nasser <fnasser@redhat.com> writes:
> > The only way to make sure you get the bit patterns you wanted is to
> > initialize the integral members of the union with those bit patterns.
> > You just want them to be different from a NaN or an Inf, because they
> > cause trouble in comparisons.
> > 
> > Am I making any sense?
> 
> I believe there will be many failures before that happen.
> 
> But, yes, loading the variables with known bit patterns would be immune
> to that.  On the other hand, what would be the bit  pattern?  If we use
> the IEEE one it may break in systems that do not use IEEE.

I think assigning a floating-point constant, which is clearly within
the range of the type, is the most portable way to get a real
floating-point value into the variable.  The values I chose should
have interesting bits throughout the mantissa, so we'll notice if
they're truncated.

So I still think the patch I posted is okay.

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

[Fernando Nasser]

Jim Blandy wrote:
> 
> I think assigning a floating-point constant, which is clearly within
> the range of the type, is the most portable way to get a real
> floating-point value into the variable.  The values I chose should
> have interesting bits throughout the mantissa, so we'll notice if
> they're truncated.
> 
> So I still think the patch I posted is okay.

OK.  Just update the comments to reflect what was discussed here (if
needed) and I am happy. 

Eli and Michael, do you still object to this change?  

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

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

[Michael Snyder]

Fernando Nasser wrote:
> 
> Jim Blandy wrote:
> >
> > I think assigning a floating-point constant, which is clearly within
> > the range of the type, is the most portable way to get a real
> > floating-point value into the variable.  The values I chose should
> > have interesting bits throughout the mantissa, so we'll notice if
> > they're truncated.
> >
> > So I still think the patch I posted is okay.
> 
> OK.  Just update the comments to reflect what was discussed here (if
> needed) and I am happy.
> 
> Eli and Michael, do you still object to this change?

I never did object to it.  I think Jim's basically on the right track.

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

[Eli Zaretskii]

On Wed, 6 Jun 2001, Fernando Nasser wrote:

> Eli and Michael, do you still object to this change?  

I do.  I think this change subverts Michael's goal, which was to make
sure GDB only looks at the bits we think it should.  This requires an
absolute certainty in the bit pattern that gets into the program.  You
cannot be certain about this kind of things without actually putting
the bit pattern into the variable.

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

[Eli Zaretskii]

On 6 Jun 2001, Jim Blandy wrote:

> The values I chose should have interesting bits throughout the
> mantissa, so we'll notice if they're truncated.

You cannot be sure those bits get intact into the program.

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

[Jim Blandy]

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.

This seems silly.

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

[Michael Snyder]

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.

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

[Fernando Nasser]

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

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

[Michael Snyder]

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.

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

[Jim Blandy]

Michael Snyder <msnyder@cygnus.com> writes:
> 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.

I don't think my patch breaks this property.  After I write to
testval.float_testval, the subsequent bytes are still 0xff.  And if a
double is no smaller than a float, it works for the double test, too.

If we're trying to catch more-bits-than-appropriate comparisons,
shouldn't the *_resultval variables be in a union with a distinct
background pattern, too?  Say, zeros?

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

[Eli Zaretskii]

On Wed, 6 Jun 2001, Michael Snyder wrote:

> 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.

So it sounds like my guess was right: you did want to be able to
detect variations in even a single bit.  I think this cannot be done
reliably with a literal FP constant, because the compiler and inherent
FP inaccuracies get in the way.

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

[Eli Zaretskii]

On 6 Jun 2001, Jim Blandy wrote:

> 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.

Yes.

> When, in fact, the exact problem I'm trying to fix is
> that someone's first shot at the former strategy produced a NaN.

That's because the bit pattern used by the original code was a bit
pattern of a NaN in the first place.  In other words, we've got
exactly what we were asking for.  You cannot expect that with a
literal FP constant like the one you used.

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

[Michael Snyder]

Eli Zaretskii wrote:
> 
> On 6 Jun 2001, Jim Blandy wrote:
> 
> > 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.
> 
> Yes.
> 
> > When, in fact, the exact problem I'm trying to fix is
> > that someone's first shot at the former strategy produced a NaN.
> 
> That's because the bit pattern used by the original code was a bit
> pattern of a NaN in the first place.  In other words, we've got
> exactly what we were asking for.  You cannot expect that with a
> literal FP constant like the one you used.

I was not specifically trying to create a NaN -- 
just a recognizeable bit pattern.

Michael

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

[Eli Zaretskii]

> Date: Thu, 07 Jun 2001 10:38:10 -0700
> From: Michael Snyder <msnyder@cygnus.com>
> > 
> > That's because the bit pattern used by the original code was a bit
> > pattern of a NaN in the first place.  In other words, we've got
> > exactly what we were asking for.  You cannot expect that with a
> > literal FP constant like the one you used.
> 
> I was not specifically trying to create a NaN -- 
> just a recognizeable bit pattern.

Yes, that's what I meant.  Sorry if my wording implied something
different.

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

[Michael Meissner]

On Wed, Jun 06, 2001 at 09:15:58AM +0300, Eli Zaretskii wrote:
> > From: Jim Blandy <jimb@zwingli.cygnus.com>
> > Date: Tue,  5 Jun 2001 22:41:45 -0500 (EST)
> > 
> > !   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
> > !   float_resultval     = float_func ();		
> > !   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
> > !   double_resultval    = double_func ();		
> 
> I think it is better to initialize the integral members of the union
> with an explicit bit pattern, just not a pattern which gets
> interpreted as a NaN of an Inf.  With initialization such as above,
> you risk losing due to subtleties of compile-time conversion of a
> literal constant to a floating-point value.  This is a GDB test suite,
> so we are not interested in testing the compiler.

Which means the test suite will break if you ever run it on a machine that
doesn't have IEEE floating point, such as the VAX if anybody still builds gdb
for that machine.  There are also mixed endian machines, where the bytes are
ordered one way, but the order of the words is different.  In supporting
embedded processors, we occasionally run into machines with weird floating
point formats, or that use IEEE formats, but don't support infinities,
denormals, or nans.  Also, there are a number of embedded targets that only
have single precision hardware floating point, and want sizeof(float) ==
sizeof(double).

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

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

[Fernando Nasser]

Michael Meissner wrote:
> 
> On Wed, Jun 06, 2001 at 09:15:58AM +0300, Eli Zaretskii wrote:
> > > From: Jim Blandy <jimb@zwingli.cygnus.com>
> > > Date: Tue,  5 Jun 2001 22:41:45 -0500 (EST)
> > >
> > > !   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
> > > !   float_resultval     = float_func ();
> > > !   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
> > > !   double_resultval    = double_func ();
> >
> > I think it is better to initialize the integral members of the union
> > with an explicit bit pattern, just not a pattern which gets
> > interpreted as a NaN of an Inf.  With initialization such as above,
> > you risk losing due to subtleties of compile-time conversion of a
> > literal constant to a floating-point value.  This is a GDB test suite,
> > so we are not interested in testing the compiler.
> 
> Which means the test suite will break if you ever run it on a machine that
> doesn't have IEEE floating point, such as the VAX if anybody still builds gdb
> for that machine.  There are also mixed endian machines, where the bytes are
> ordered one way, but the order of the words is different.  In supporting
> embedded processors, we occasionally run into machines with weird floating
> point formats, or that use IEEE formats, but don't support infinities,
> denormals, or nans.  Also, there are a number of embedded targets that only
> have single precision hardware floating point, and want sizeof(float) ==
> sizeof(double).
> 

This is the point in favor of Jim's patch.  It is more portable.  The
compiler will convert the literal to whatever format is used in that
system.

I think Michael Meissner just gave a definitive reason for Jim's patch
to go in as is.

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

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

[Eli Zaretskii]

On Wed, 6 Jun 2001, Michael Meissner wrote:

> > I think it is better to initialize the integral members of the union
> > with an explicit bit pattern, just not a pattern which gets
> > interpreted as a NaN of an Inf.  With initialization such as above,
> > you risk losing due to subtleties of compile-time conversion of a
> > literal constant to a floating-point value.  This is a GDB test suite,
> > so we are not interested in testing the compiler.
> 
> Which means the test suite will break if you ever run it on a machine that
> doesn't have IEEE floating point, such as the VAX if anybody still builds gdb
> for that machine.

Those machines obviously require a different bit pattern.  But the
principle is the same: if you want a specific bit pattern in an FP
variable, the only sure way is to put it there manually.

In other words, portability has nothing to do with this.  We are
trying to see if an FP value is handled correctly by GDB on a
particular machine, and those tests are inherently machine specific.

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

[Fernando Nasser]

Approved.

Jim Blandy wrote:
> 
> 2001-06-05  Jim Blandy  <jimb@redhat.com>
> 
>         * gdb.base/return2.exp (main): Use values to test float and double
>         returns that are not NaN's, to avoid being confused by IEEE
>         comparison rules.
> 
> Index: gdb/testsuite/gdb.base/return2.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/return2.c,v
> retrieving revision 1.2
> diff -c -r1.2 return2.c
> *** gdb/testsuite/gdb.base/return2.c    2000/12/20 14:34:27     1.2
> --- gdb/testsuite/gdb.base/return2.c    2001/06/06 03:39:25
> ***************
> *** 84,91 ****
>     int_resultval       = int_func ();          /* short_checkpoint */
>     long_resultval      = long_func ();         /* int_checkpoint */
>     long_long_resultval = long_long_func ();    /* long_checkpoint */
> !   float_resultval     = float_func ();                /* long_long_checkpoint */
> !   double_resultval    = double_func ();               /* float_checkpoint */
>     main_test = 1;                              /* double_checkpoint */
>     return 0;
>   }
> --- 84,110 ----
>     int_resultval       = int_func ();          /* short_checkpoint */
>     long_resultval      = long_func ();         /* int_checkpoint */
>     long_long_resultval = long_long_func ();    /* long_checkpoint */
> !
> !   /* On machines using IEEE floating point, the test pattern of all
> !      1-bits established above turns out to be a floating-point NaN
> !      ("Not a Number").  According to the IEEE rules, NaN's aren't even
> !      equal to themselves.  This can lead to stupid conversations with
> !      GDB like:
> !
> !        (gdb) p testval.float_testval == testval.float_testval
> !        $7 = 0
> !        (gdb)
> !
> !      This is the correct answer, but it's not the sort of thing
> !      return2.exp wants to see.  So to make things work the way they
> !      ought, we'll set aside the `union' cleverness and initialize the
> !      test values explicitly here.  These values have interesting bits
> !      throughout the value, so we'll still detect truncated values.  */
> !
> !   testval.float_testval = 2.7182818284590452354;/* long_long_checkpoint */
> !   float_resultval     = float_func ();
> !   testval.double_testval = 3.14159265358979323846; /* float_checkpoint */
> !   double_resultval    = double_func ();
>     main_test = 1;                              /* double_checkpoint */
>     return 0;
>   }

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