Hi guys.

I have just had some problems resolved while building PostgreSQL 7.4.2 
on Tru64 UNIX 5.1B.

File "./src/backend/utils/adt/float.c" uses "NAN" on two spots. It ahs a 
fall-back definition of NAN as:

#define NAN 0.0/0.0

This compiles on Tru64 4.0D (the compiler swallows it), but fails on 
Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file 
complaining on that constant evaluation. The best way to solve it is to 
use system definition of "Infinity Constants". This definition is best 
placed in src/include/port/osf1.h This will work on both 5.1B and 4.0D.

This is the patch:

Papa-Legba:/home/r/root/5.1/postgresql-7.4.2# diff -c 
src/include/port/osf.h_ORIG src/include/port/osf.h
*** src/include/port/osf.h_ORIG Sun May 16 14:14:22 2004
--- src/include/port/osf.h      Sun May 16 14:17:57 2004
***************
*** 5,7 ****
--- 5,17 ----
  /*typedef msemaphore slock_t;*/
  #include <alpha/builtins.h>
  typedef volatile long slock_t;
+
+ /*
+  * This is for NaN (Not a Number) definition.
+  * Note that general definition in PostgreSQL is not type specific, IOW,
+  * PgSQL's definition can be used in all floating point contexts. The
+  * definition given here is for "double NaN", since all sources using it
+  * are using it in "double float" context.
+  */
+ #include <nan.h>
+ #define NAN   DBL_INFINITY

The compilation has went smoothly, I'll try to run regression tests. 
Will let you know if something fails.

Nix.

Sun, 16 May 2004 15:07:51 +0200
Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu>
PgSQL 7.4.2 - NaN on Tru64 UNIX
Nikola Milutinovic wrote:

> + #define NAN   DBL_INFINITY
> 
> The compilation has went smoothly, I'll try to run regression tests. 
> Will let you know if something fails.

Hate to reply to myself, but here goes.

With NAN defined as "DBL_INFINITY" I get 3 failed regression test, most 
notably "float8" test.

With NAN defined as "DBL_QNAN" (double float Quiet NaN) I get just one, 
"float8".

With NAN defined as "DBL_SNAN" (double float Signalling NaN) I get one 
error, "float8".

The "problem" is the same in all three cases, an expression that is 
supposed to cause overflow, does so, but the output error text is 
slightly different. Here is the DIFF file:

*** ./expected/float8.out       Thu Sep 25 08:58:06 2003
--- ./results/float8.out        Mon May 17 08:37:51 2004
***************
*** 247,253 ****
      SET f1 = FLOAT8_TBL.f1 * '-1'
      WHERE FLOAT8_TBL.f1 > '0.0';
   SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR:  type "double precision" value out of range: overflow
   SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
   ERROR:  result is out of range
   SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
--- 247,254 ----
      SET f1 = FLOAT8_TBL.f1 * '-1'
      WHERE FLOAT8_TBL.f1 > '0.0';
   SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR:  floating-point exception
! DETAIL:  An invalid floating-point operation was signaled. This 
probably means an out-of-range result or an invalid operation, suc
h as division by zero.
   SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
   ERROR:  result is out of range
   SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
***************
*** 270,276 ****

   -- test for over- and underflow
   INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
! ERROR:  "10e400" is out of range for type double precision
   INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
   ERROR:  "-10e400" is out of range for type double precision
   INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
--- 271,277 ----

   -- test for over- and underflow
   INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
! ERROR:  invalid input syntax for type double precision: "10e400"
   INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
   ERROR:  "-10e400" is out of range for type double precision
   INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');

======================================================================

Any comments?

Nix.

Mon, 17 May 2004 09:00:39 +0200
Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu>
Re: PgSQL 7.4.2 - NaN on Tru64 UNIX
Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu> writes:
> [ about NaN on Tru64 ]
> This compiles on Tru64 4.0D (the compiler swallows it), but fails on 
> Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file 
> complaining on that constant evaluation. The best way to solve it is to 
> use system definition of "Infinity Constants":
> ...
> + #define NAN   DBL_INFINITY

Current CVS tip will probably fail with this, because we expect the
platform to distinguish between NaN and Infinity.  Could you retry your
experiments with a recent snapshot and let us know what seems best now?

			regards, tom lane

Tue, 18 May 2004 23:41:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PgSQL 7.4.2 - NaN on Tru64 UNIX 
Tom Lane wrote:

> Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu> writes:
> 
>>[ about NaN on Tru64 ]
>>This compiles on Tru64 4.0D (the compiler swallows it), but fails on 
>>Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file 
>>complaining on that constant evaluation. The best way to solve it is to 
>>use system definition of "Infinity Constants":
>>...
>>+ #define NAN   DBL_INFINITY
> 
> 
> Current CVS tip will probably fail with this, because we expect the
> platform to distinguish between NaN and Infinity.  Could you retry your
> experiments with a recent snapshot and let us know what seems best now?

Appologies to all, I have been blind!

Disregard my proposed patches. One of users on Tru64 mailing list 
pointed me to a correct solution - add "-ieee" to CC flags. I took a 
look at templates for OSF1 in PgSQL and they read:

CFLAGS="-O -ieee"

Since I was putting my own definition for CFLAGS, I left out "-ieee". I 
have reverted ./src/include/port/osf1.h to the the original and changed 
CFLAGS in ./src/Makefile.global to include "-ieee". Then I rebuild 
./src/backend/utils/adt/float.o (I'll rebuild the whole PostgreSQL in a 
moment) and ran regression tests.

All 93 tests passed.

So, again, my apologies to all, no change neccesary.

Nix.

Wed, 19 May 2004 08:42:23 +0200
Nikola Milutinovic <Nikola.Milutinovic@ev.co.yu>
Re: PgSQL 7.4.2 - NaN on Tru64 UNIX - CORRECTION!!!

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Nikola Milutinovic wrote:
> Hi guys.
> 
> I have just had some problems resolved while building PostgreSQL 7.4.2 
> on Tru64 UNIX 5.1B.
> 
> File "./src/backend/utils/adt/float.c" uses "NAN" on two spots. It ahs a 
> fall-back definition of NAN as:
> 
> #define NAN 0.0/0.0
> 
> This compiles on Tru64 4.0D (the compiler swallows it), but fails on 
> Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file 
> complaining on that constant evaluation. The best way to solve it is to 
> use system definition of "Infinity Constants". This definition is best 
> placed in src/include/port/osf1.h This will work on both 5.1B and 4.0D.
> 
> This is the patch:
> 
> Papa-Legba:/home/r/root/5.1/postgresql-7.4.2# diff -c 
> src/include/port/osf.h_ORIG src/include/port/osf.h
> *** src/include/port/osf.h_ORIG Sun May 16 14:14:22 2004
> --- src/include/port/osf.h      Sun May 16 14:17:57 2004
> ***************
> *** 5,7 ****
> --- 5,17 ----
>   /*typedef msemaphore slock_t;*/
>   #include <alpha/builtins.h>
>   typedef volatile long slock_t;
> +
> + /*
> +  * This is for NaN (Not a Number) definition.
> +  * Note that general definition in PostgreSQL is not type specific, IOW,
> +  * PgSQL's definition can be used in all floating point contexts. The
> +  * definition given here is for "double NaN", since all sources using it
> +  * are using it in "double float" context.
> +  */
> + #include <nan.h>
> + #define NAN   DBL_INFINITY
> 
> The compilation has went smoothly, I'll try to run regression tests. 
> Will let you know if something fails.
> 
> Nix.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 9 Jul 2004 21:49:54 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PgSQL 7.4.2 - NaN on Tru64 UNIX

OK, I will use "DBL_QNAN" for the patch.

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Nikola Milutinovic wrote:
> Nikola Milutinovic wrote:
> 
> > + #define NAN   DBL_INFINITY
> > 
> > The compilation has went smoothly, I'll try to run regression tests. 
> > Will let you know if something fails.
> 
> Hate to reply to myself, but here goes.
> 
> With NAN defined as "DBL_INFINITY" I get 3 failed regression test, most 
> notably "float8" test.
> 
> With NAN defined as "DBL_QNAN" (double float Quiet NaN) I get just one, 
> "float8".
> 
> With NAN defined as "DBL_SNAN" (double float Signalling NaN) I get one 
> error, "float8".
> 
> The "problem" is the same in all three cases, an expression that is 
> supposed to cause overflow, does so, but the output error text is 
> slightly different. Here is the DIFF file:
> 
> *** ./expected/float8.out       Thu Sep 25 08:58:06 2003
> --- ./results/float8.out        Mon May 17 08:37:51 2004
> ***************
> *** 247,253 ****
>       SET f1 = FLOAT8_TBL.f1 * '-1'
>       WHERE FLOAT8_TBL.f1 > '0.0';
>    SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
> ! ERROR:  type "double precision" value out of range: overflow
>    SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
>    ERROR:  result is out of range
>    SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
> --- 247,254 ----
>       SET f1 = FLOAT8_TBL.f1 * '-1'
>       WHERE FLOAT8_TBL.f1 > '0.0';
>    SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
> ! ERROR:  floating-point exception
> ! DETAIL:  An invalid floating-point operation was signaled. This 
> probably means an out-of-range result or an invalid operation, suc
> h as division by zero.
>    SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
>    ERROR:  result is out of range
>    SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
> ***************
> *** 270,276 ****
> 
>    -- test for over- and underflow
>    INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
> ! ERROR:  "10e400" is out of range for type double precision
>    INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
>    ERROR:  "-10e400" is out of range for type double precision
>    INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
> --- 271,277 ----
> 
>    -- test for over- and underflow
>    INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
> ! ERROR:  invalid input syntax for type double precision: "10e400"
>    INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
>    ERROR:  "-10e400" is out of range for type double precision
>    INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
> 
> ======================================================================
> 
> Any comments?
> 
> Nix.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 9 Jul 2004 21:52:19 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] [GENERAL] PgSQL 7.4.2 - NaN on Tru64 UNIX

Both patches withdrawn by author.

---------------------------------------------------------------------------

Nikola Milutinovic wrote:
> Hi guys.
> 
> I have just had some problems resolved while building PostgreSQL 7.4.2 
> on Tru64 UNIX 5.1B.
> 
> File "./src/backend/utils/adt/float.c" uses "NAN" on two spots. It ahs a 
> fall-back definition of NAN as:
> 
> #define NAN 0.0/0.0
> 
> This compiles on Tru64 4.0D (the compiler swallows it), but fails on 
> Tru64 UNIX 5.1B. Both basic CC and DTK Compaq CC break on that file 
> complaining on that constant evaluation. The best way to solve it is to 
> use system definition of "Infinity Constants". This definition is best 
> placed in src/include/port/osf1.h This will work on both 5.1B and 4.0D.
> 
> This is the patch:
> 
> Papa-Legba:/home/r/root/5.1/postgresql-7.4.2# diff -c 
> src/include/port/osf.h_ORIG src/include/port/osf.h
> *** src/include/port/osf.h_ORIG Sun May 16 14:14:22 2004
> --- src/include/port/osf.h      Sun May 16 14:17:57 2004
> ***************
> *** 5,7 ****
> --- 5,17 ----
>   /*typedef msemaphore slock_t;*/
>   #include <alpha/builtins.h>
>   typedef volatile long slock_t;
> +
> + /*
> +  * This is for NaN (Not a Number) definition.
> +  * Note that general definition in PostgreSQL is not type specific, IOW,
> +  * PgSQL's definition can be used in all floating point contexts. The
> +  * definition given here is for "double NaN", since all sources using it
> +  * are using it in "double float" context.
> +  */
> + #include <nan.h>
> + #define NAN   DBL_INFINITY
> 
> The compilation has went smoothly, I'll try to run regression tests. 
> Will let you know if something fails.
> 
> Nix.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 10 Jul 2004 15:22:17 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] PgSQL 7.4.2 - NaN on Tru64 UNIX