Alessio Bragadini <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sounds good; could you check the regress tests too?
> *** ./expected/float8-fp-exception.outThu Mar 30 10:46:00 2000
> --- ./results/float8.out Tue Apr 17 20:09:17 2001
> ***
> *** 214,220
> SET
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[EMAIL PROTECTED]
APL Financial Services
Alessio Bragadini <[EMAIL PROTECTED]> 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"
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/templa
> Mmmmhhh... Failed the int8 test
Sorry, float8
--
Alessio F. Bragadini[EMAIL PROTECTED]
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750
"It is more complicated than you think"
-- The Eighth Networking
Alessio Bragadini <[EMAIL PROTECTED]> 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 wor
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-maxba
Thomas Lockhart <[EMAIL PROTECTED]> 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". (constfold
> 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
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
> 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
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/
12 matches
Mail list logo
