Thread: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)
Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)
From
Bruce Momjian
Date:
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, Pennsylvania19026
Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A with Compaq C T6.4-212 (dtk)
From
Thomas Lockhart
Date:
> 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
Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A
From
Alessio Bragadini
Date:
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
Re: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A
From
Alessio Bragadini
Date:
> 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
Re: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A
From
Alessio Bragadini
Date:
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
Re: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A
From
Alessio Bragadini
Date:
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*** ./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' ; ======================================================================
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