Обсуждение: float4 regression test failed on linux parisc

I am getting a float4 regression test failure.  I have extracted the SQL from both the float4 and float8 tests below.

Both should return NAN

I looked at the code,  The float4div does the operation as float8's then checks the value.  The value is a valid 
float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If I put the cast in I get the expected 
results (NAN).


SELECT 'Infinity'::float4 / 'Infinity'::float4;
psql:test.sql:1: ERROR:  type "real" value out of range: overflow

SELECT 'Infinity'::float8 / 'Infinity'::float8;?column? 
----------     NaN
(1 row)

"Jim Buttafuoco" <jim@contactbda.com> writes:
> I am getting a float4 regression test failure.  I have extracted the SQL from both the float4 and float8 tests below.

 
> Both should return NAN

> I looked at the code,  The float4div does the operation as float8's then checks the value.  The value is a valid 
> float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If I put the cast in I get the expected 
> results (NAN).

This report is about as clear as mud :-(.  What platform is this, and
what source code change are you proposing *exactly* ?
        regards, tom lane

Tom Lane wrote:
> "Jim Buttafuoco" <jim@contactbda.com> writes:
>
>>I am getting a float4 regression test failure.  I have extracted the SQL from both the float4 and float8 tests below.
 
>>Both should return NAN
>
>
>>I looked at the code,  The float4div does the operation as float8's then checks the value.  The value is a valid
>>float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If I put the cast in I get the expected
>>results (NAN).
>
>
> This report is about as clear as mud :-(.  What platform is this, and

I believe the parisc platform is the HP 9000 series. Probably running
Debian.

http://parisc-linux.org

Sincerely,

Joshua D. Drake


> what source code change are you proposing *exactly* ?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


--
Command Prompt, Inc., your source for PostgreSQL replication,
professional support, programming, managed services, shared
and dedicated hosting. Home of the Open Source Projects plPHP,
plPerlNG, pgManage,  and pgPHPtoolkit.
Contact us now at: +1-503-667-4564 - http://www.commandprompt.com

Source: CSV HEAD (As of yesterday)
Platform: HP PARISC (HP 710)
OS: Debian Sarge
File: src/backend/utils/adt/float.c
Change:       CheckFloat4Val(result);
To:       CheckFloat4Val((float4)result);

I tested this on my parisc box and it passed all tests.  This could just be an issue with a very old CPU/floating 
point unit.

I can send a patch in, but since this seems to work on other platforms, I thought I would ask here first.

Sorry about the cryptic message, it was before my first cup of java.

Jim


------------------------------------------------
Datum
float4div(PG_FUNCTION_ARGS)
{       float4          arg1 = PG_GETARG_FLOAT4(0);       float4          arg2 = PG_GETARG_FLOAT4(1);       double
   result;
 
       if (arg2 == 0.0)               ereport(ERROR,                               (errcode(ERRCODE_DIVISION_BY_ZERO),
                             errmsg("division by zero")));
 
       /* Do division in float8, then check for overflow */       result = (float8) arg1 / (float8) arg2;
       CheckFloat4Val(result);
       PG_RETURN_FLOAT4((float4) result);
}



---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jim Buttafuoco" <jim@contactbda.com>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 01 Feb 2005 12:06:30 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

> "Jim Buttafuoco" <jim@contactbda.com> writes:
> > I am getting a float4 regression test failure.  I have extracted the SQL from both the float4 and float8 tests 
below.  
> > Both should return NAN
> 
> > I looked at the code,  The float4div does the operation as float8's then checks the value.  The value is a valid 
> > float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If I put the cast in I get the expected

> > results (NAN).
> 
> This report is about as clear as mud :-(.  What platform is this, and
> what source code change are you proposing *exactly* ?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
------- End of Original Message -------

"Jim Buttafuoco" <jim@contactbda.com> writes:
> I am trying to get this system working for the buildfarm as there are
> NO other HP PARISC system on the farm.

I still use a PA-RISC machine as my primary development environment,
so I can assure you that platform gets tested every day.  I'm not
particularly interested in catering to a broken compiler by removing
the ability to detect float4 overflow, which is what the result would be
if we use your patch.

In short: if you want this to work, I think you should file a bug with
Debian, not here.
        regards, tom lane

Tom,

The issue is with a select 'Infinity'::float4/'Infinity'::float4; which should return NAN.  without the cast I get the

overflow message from CheckFloat4Val with the cast I get NAN (as expected). How about testing for isnan() inside 
CheckFloat4Val (just for PARISC / Linux)? 

I am trying to get this system working for the buildfarm as there are NO other HP PARISC system on the farm.

Jim


---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 01 Feb 2005 17:13:52 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

> "Jim Buttafuoco" <jim@contactbda.com> writes:
> > Change:
> >         CheckFloat4Val(result);
> > To:
> >         CheckFloat4Val((float4)result);
> 
> CheckFloat4Val is defined to take a double, so whatever the above is
> accomplishing is wrong: probably it's masking an out-of-range result.
> I think you've hit a bug in Debian's version of gcc for PA-RISC.
> 
>             regards, tom lane
------- End of Original Message -------

"Jim Buttafuoco" <jim@contactbda.com> writes:
> Change:
>         CheckFloat4Val(result);
> To:
>         CheckFloat4Val((float4)result);

CheckFloat4Val is defined to take a double, so whatever the above is
accomplishing is wrong: probably it's masking an out-of-range result.
I think you've hit a bug in Debian's version of gcc for PA-RISC.
        regards, tom lane

Tom,

I'm back with this issue.  I have comparied the src/backend/utils/adt/float.c from 7.4.6 against CVS HEAD.  There was 
some work done on the infinity handling (don't know who, I am NOT a CVS expert/user).  The problem I see is that the 
float4in does a check to see if the value is infinity BEFORE calling CheckFloat4Val (this was added for 8.0) but the 
float4div (and friends) doesn't.  All I want to do is add a check in CheckFloat4Val for infinity (and remove the 
individual checks before the CheckFloat4Val call in other routines).  

I hope I have explained my problem and solution. 

Jim
---------- Forwarded Message -----------
From: "Jim Buttafuoco" <jim@contactbda.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 1 Feb 2005 17:20:17 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

Tom,

The issue is with a select 'Infinity'::float4/'Infinity'::float4; which should return NAN.  without the cast I get the

overflow message from CheckFloat4Val with the cast I get NAN (as expected). How about testing for isnan() inside 
CheckFloat4Val (just for PARISC / Linux)?

I am trying to get this system working for the buildfarm as there are NO other HP PARISC system on the farm.

Jim

---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 01 Feb 2005 17:13:52 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc

> "Jim Buttafuoco" <jim@contactbda.com> writes:
> > Change:
> >         CheckFloat4Val(result);
> > To:
> >         CheckFloat4Val((float4)result);
> 
> CheckFloat4Val is defined to take a double, so whatever the above is
> accomplishing is wrong: probably it's masking an out-of-range result.
> I think you've hit a bug in Debian's version of gcc for PA-RISC.
> 
>             regards, tom lane
------- End of Original Message -------
------- End of Forwarded Message -------

"Jim Buttafuoco" <jim@contactbda.com> writes:
> All I want to do is add a check in CheckFloat4Val for infinity (and remove the 
> individual checks before the CheckFloat4Val call in other routines).  

That's not at all what you proposed before, and it would have vastly
more side-effects than just removing the platform-dependent behavior
you are on about.  If we did that then this would work:

regression=# select ('infinity'::float4) / (1::float4);
ERROR:  type "real" value out of range: overflow

... which arguably it ought to, but you'd be changing the behavior
everywhere not just for your broken compiler.

I think the real question we ought to face up to sometime is what it is
we are trying to accomplish with CheckFloat4Val and CheckFloat8Val in
the first place.  The latter routine in particular seems pretty
ill-advised to me: if something can be represented as a double then why
don't we just allow it?

ISTM that what we really want is to reject out-of-range results, as in
these examples:

regression=# select (1e37::float4) / (1e-37::float4);
ERROR:  type "real" value out of range: overflow
regression=# select (1e300::float8) / (1e-37::float8);
ERROR:  type "double precision" value out of range: overflow
regression=#

On machines that have IEEE infinity, I think it would work to report
overflow if the result is infinity when neither input is.  But I dunno
how well that works on non-IEEE hardware.  Also, what about rejecting
NaN results?  Thoughts anyone?
        regards, tom lane

Tom,

The other option is to note that on older ( and I mean real old systems where the fp unit is sub par) systems that 
this test is likely to fail. I have now seen this on my real old Alpha and now HP PARISC systems.  Is there a way to 
just modify the regression test to pass by these test on these platforms?

Jim


---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 08 Feb 2005 10:25:26 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

> "Jim Buttafuoco" <jim@contactbda.com> writes:
> > All I want to do is add a check in CheckFloat4Val for infinity (and remove the 
> > individual checks before the CheckFloat4Val call in other routines).
> 
> That's not at all what you proposed before, and it would have vastly
> more side-effects than just removing the platform-dependent behavior
> you are on about.  If we did that then this would work:
> 
> regression=# select ('infinity'::float4) / (1::float4);
> ERROR:  type "real" value out of range: overflow
> 
> ... which arguably it ought to, but you'd be changing the behavior
> everywhere not just for your broken compiler.
> 
> I think the real question we ought to face up to sometime is what it is
> we are trying to accomplish with CheckFloat4Val and CheckFloat8Val in
> the first place.  The latter routine in particular seems pretty
> ill-advised to me: if something can be represented as a double then why
> don't we just allow it?
> 
> ISTM that what we really want is to reject out-of-range results, as in
> these examples:
> 
> regression=# select (1e37::float4) / (1e-37::float4);
> ERROR:  type "real" value out of range: overflow
> regression=# select (1e300::float8) / (1e-37::float8);
> ERROR:  type "double precision" value out of range: overflow
> regression=#
> 
> On machines that have IEEE infinity, I think it would work to report
> overflow if the result is infinity when neither input is.  But I dunno
> how well that works on non-IEEE hardware.  Also, what about rejecting
> NaN results?  Thoughts anyone?
> 
>             regards, tom lane
------- End of Original Message -------

"Jim Buttafuoco" <jim@contactbda.com> writes:
> this test is likely to fail. I have now seen this on my real old Alpha
> and now HP PARISC systems.

It works fine on PARISC, and has ever since I've been associated with
this project --- I run these tests multiple times a day on old HP
hardware, and they have always passed with every compiler I've used
(both gcc and HP's).  Lots of people have reported clean passes on Alpha
as well.  One more time: you have a compiler bug, and you really ought
to be griping to the gcc people not us.
        regards, tom lane

except isinf() works just fine on my system.  It's just when CheckFloat4Val is called with infinity as the "val" you 
you get the overflow message.  If I move the isinf into CheckFloat4Val all is fine.  

If you don't want to fix this, it's fine with me.  I am just reporting problems and trying to fix them.  I will shut 
up now and put my energy into other causes!

Jim



---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 08 Feb 2005 11:42:11 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

> "Jim Buttafuoco" <jim@contactbda.com> writes:
> > this test is likely to fail. I have now seen this on my real old Alpha
> > and now HP PARISC systems.
> 
> It works fine on PARISC, and has ever since I've been associated with
> this project --- I run these tests multiple times a day on old HP
> hardware, and they have always passed with every compiler I've used
> (both gcc and HP's).  Lots of people have reported clean passes on Alpha
> as well.  One more time: you have a compiler bug, and you really ought
> to be griping to the gcc people not us.
> 
>             regards, tom lane
------- End of Original Message -------