Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)

OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us
how to get a NAN value. Zero is not it. I see the following mentions
of NAN in the code. Does NAN exist in one of your /usr/include files?

We had at least three reports of successful compilation on Tru64 4.0[dg]
and 5.0. So perhaps there is something else going on, or some other
optional packages in an include path?

- Thomas

No, those don't do it. We need an actual NaN value. These are just
flags, I think.

There are two things I found from fp_class.h, FP_SNAN (a signaling NaN),
and FP_QNAN (a quiet NaN). Don't know which you want:
alphapc.ourservers.net> grep FP_SNAN /usr/include/*
/usr/include/fp_class.h:#define FP_SNAN 0
alphapc.ourservers.net> grep FP_QNAN /usr/include/*
/usr/include/fp_class.h:#define FP_QNAN 1

There is an isnan() function on v5.0a.
I'll be sending you the manpage.

The problem is that we have to assign NAN to variables sometimes. That
is why were were doing 0.0/0.0, to generate an NAN that could be used
later in the code.

I understand your compiler is saying it can't compute that at compile
time. Maybe a computation that is preformed to set the value somehow.

OK, looks like we have a Tru64 problem with 7.1 too. Can you tell us
how to get a NAN value. Zero is not it. I see the following mentions
of NAN in the code. Does NAN exist in one of your /usr/include files?

include/port/qnx4.h:18:#ifndef NAN
include/port/qnx4.h:24:#define NAN (*(const double *) __nan)
include/port/qnx4.h:25:#endif /* NAN */
include/port/solaris.h:43:#ifndef NAN
include/port/solaris.h:51:#define NAN \
include/port/solaris.h:58:#define NAN (0.0/0.0)
include/port/solaris.h:62:#endif /* not NAN */
include/utils/timestamp.h:64:#ifdef NAN
include/utils/timestamp.h:65:#define DT_INVALID (NAN)
include/utils/timestamp.h:80:#ifdef NAN
include/utils/timestamp.h:104:#ifdef NAN
backend/port/qnx4/isnan.c:22: return !memcmp(&dsrc, &NAN, sizeof(double));
backend/utils/adt/float.c:106:#ifndef NAN
backend/utils/adt/float.c:107:#define NAN (0.0/0.0)
backend/utils/adt/float.c:251: val = NAN;
backend/utils/adt/numeric.c:45:#ifndef NAN
backend/utils/adt/numeric.c:46:#define NAN (0.0/0.0)
backend/utils/adt/numeric.c:1718: PG_RETURN_FLOAT8(NAN);
backend/utils/adt/numeric.c:1763: PG_RETURN_FLOAT4((float4) NAN);
backend/utils/adt/numeric.c:2269: var->sign = NUMERIC_POS; /* anything but NAN... */

It _doesn't_ compile on Tru64:
gmake -C adt SUBSYS.o
gmake[4]: Entering directory `/usr/users/dcarmich/postgresql-7.1/src/
backend/utils/adt'
cc -std -O4 -Olimit 2000 -I../../../../src/include -c -o float.o float.c
cc: Error: float.c, line 251: In this statement, the libraries on this
platform do not yet support compile-time evaluation of the constant
expression "0.0/0.0". (constfoldns)
val = NAN;
------------------------------^
gmake[4]: *** [float.o] Error 1
gmake[4]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/backend
/utils/adt'
gmake[3]: *** [adt-recursive] Error 2
gmake[3]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/backend
/utils'
gmake[2]: *** [utils-recursive] Error 2
gmake[2]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src/
backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/usr/users/dcarmich/postgresql-7.1/src'
gmake: *** [all] Error 2

(Sorry about the quoting, don't know how to remove it in VMS EDT.)

Please try 7.1. It should work fine.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name : Douglas Carmichael
Your email address : dcarmich@ourservers.net

System Configuration
---------------------
Architecture (example: Intel Pentium) : DEC/Compaq Alpha

Operating System (example: Linux 2.0.26 ELF) : Compaq Tru64 UNIX v5.0A rev 1094

PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3

Compiler used (example: gcc 2.8.0) : Compaq C T6.4-212 (dtk)

Please enter a FULL description of your problem:
------------------------------------------------

I have patches to src/backend/utils/adt/float.c and
src/backend/utils/adt/numeric.c to get PostgreSQL 7.0.3 to compile on Tru64
v5.0A with Compaq C T6.4-212 (dtk).

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

N/A

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

diff -cr postgresql-7.0.3_old/src/backend/utils/adt/float.c postgresql-7.0.3/src/backend/utils/adt/float.c
*** postgresql-7.0.3_old/src/backend/utils/adt/float.c	Wed Apr 12 12:15:49 2000
--- postgresql-7.0.3/src/backend/utils/adt/float.c	Fri Apr 13 22:13:10 2001
***************
*** 68,74 ****
#include "utils/builtins.h"

#ifndef NAN
! #define NAN (0.0/0.0)
#endif

#ifndef SHRT_MAX
--- 68,74 ----
#include "utils/builtins.h"

#ifndef NAN
! #define NAN 0
#endif

#ifndef SHRT_MAX
diff -cr postgresql-7.0.3_old/src/backend/utils/adt/numeric.c postgresql-7.0.3/src/backend/utils/adt/numeric.c
*** postgresql-7.0.3_old/src/backend/utils/adt/numeric.c	Wed Apr 12 12:15:50 2000
--- postgresql-7.0.3/src/backend/utils/adt/numeric.c	Fri Apr 13 22:15:55 2001
***************
*** 41,47 ****
#endif

#ifndef NAN
! #define NAN (0.0/0.0)
#endif

--- 41,47 ----
#endif

#ifndef NAN
! #define NAN 0
#endif

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

No, those don't do it. We need an actual NaN value. These are just
flags, I think.

gmake -C adt SUBSYS.o
gmake[4]: Entering directory `/usr/users/dcarmich/postgresql-7.1/src/
backend/utils/adt'
cc -std -O4 -Olimit 2000 -I../../../../src/include -c -o float.o float.c
cc: Error: float.c, line 251: In this statement, the libraries on this
platform do not yet support compile-time evaluation of the constant
expression "0.0/0.0". (constfoldns)
val = NAN;
------------------------------^

Where does the "-O4" come from? That level of optimization probably is
forcing the compile-time constant folding, which is causing trouble.

Try backing off to "-O2" or turn off optimization all together and I'll
bet it will compile. Another possibility is to go into the adt/
subdirectory, compile float.o by cutting and pasting the line above
(substituting -O0 for -O4) and then go back up and resume the make from
the top.

- Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

cc -std -O4 -Olimit 2000 -I../../../../src/include -c -o float.o float.c
cc: Error: float.c, line 251: In this statement, the libraries on this
platform do not yet support compile-time evaluation of the constant
expression "0.0/0.0". (constfoldns)

Where does the "-O4" come from? That level of optimization probably is
forcing the compile-time constant folding, which is causing trouble.

Looks like it's coming from src/template/osf. If Douglas can confirm
that a lower -O level makes the compiler complaint go away, then we need
to change that template.

BTW, the other arm of the osf template looks pretty bogus too: isn't it
forcing no optimizations for gcc? I'd have expected CFLAGS=-O2 for gcc.

regards, tom lane

Thomas Lockhart wrote:

We had at least three reports of successful compilation on Tru64 4.0[dg]

I can add up my experience of building on Tru64 4.0f (Compaq DS20E)
without problems, using Digital's cc

./configure --with-includes=/usr/local/include
--with-libraries=/usr/local/lib --with-maxbackends=128 --with-perl
--localstatedir=/var/run/pgsql --prefix=/usr/local/pgsql
--mandir=/usr/local/man --docdir=/data/www/library

version
--------------------------------------------------------------
PostgreSQL 7.1 on alphaev67-dec-osf4.0f, compiled by cc -std

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750

"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925

Alessio Bragadini <alessio@albourne.com> writes:

Thomas Lockhart wrote:

We had at least three reports of successful compilation on Tru64 4.0[dg]

I can add up my experience of building on Tru64 4.0f (Compaq DS20E)
without problems, using Digital's cc

Would you check whether things still work on your platform if CC becomes
"cc -std -ieee" rather than just "cc -std"? (Best way to check is to
alter src/template/osf, then do the full configure/build cycle.)

regards, tom lane

Tom Lane wrote:

I can add up my experience of building on Tru64 4.0f (Compaq DS20E)
without problems, using Digital's cc

Would you check whether things still work on your platform if CC becomes
"cc -std -ieee" rather than just "cc -std"? (Best way to check is to
alter src/template/osf, then do the full configure/build cycle.)

Here we go:
All of PostgreSQL successfully made. Ready to install.

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750

"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925

Alessio Bragadini <alessio@albourne.com> writes:

Tom Lane wrote:
I can add up my experience of building on Tru64 4.0f (Compaq DS20E)
without problems, using Digital's cc

Would you check whether things still work on your platform if CC becomes
"cc -std -ieee" rather than just "cc -std"? (Best way to check is to
alter src/template/osf, then do the full configure/build cycle.)

Here we go:
All of PostgreSQL successfully made. Ready to install.

Sounds good; could you check the regress tests too?

regards, tom lane

Tom Lane wrote:

Sounds good; could you check the regress tests too?

Mmmmhhh... Failed the int8 test, but seems more a difference in the text
of the error message. The others 75 were successful.

diff attached

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750

"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925

Mmmmhhh... Failed the int8 test

Sorry, float8

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750

"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925

Alessio Bragadini <alessio@albourne.com> writes:

Tom Lane wrote:

Sounds good; could you check the regress tests too?

*** ./expected/float8-fp-exception.out	Thu Mar 30 10:46:00 2000
--- ./results/float8.out	Tue Apr 17 20:09:17 2001
***************
*** 214,220 ****
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! The last floating point operation either exceeded legal ranges or was a divide by zero
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
ERROR:  pow() result is out of range
SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
--- 214,220 ----
SET f1 = FLOAT8_TBL.f1 * '-1'
WHERE FLOAT8_TBL.f1 > '0.0';
SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR:  Bad float8 input format -- overflow
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
ERROR:  pow() result is out of range
SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;

That's fairly strange. It doesn't seem to have a problem with the
constant '1e200' as such --- notice that the next query gets the
expected result. But why would we get "Bad float8 input format"
for a calculation-result overflow? Ideas anyone?

regards, tom lane