From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Match(dot)Grun(at)thomson(dot)com |
Subject: | Re: horo(r)logy test fail on solaris (again and solved) |
Date: | 2006-09-27 13:40:09 |
Message-ID: | 451A7F39.1000101@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan napsal(a):
>
>
> Tom Lane wrote:
>> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>>
>>> But the question is if the "-fast" flag is good for postgres. The
>>> -fast flag sets "brutal" floating point optimization and some
>>> operation should have less precision. Is possible verify that
>>> floating point operation works well?
>>>
>>
>> That's a pretty good way to guarantee that you'll break the datetime
>> code.
>>
>>
>
> ! | @ 6 years | @ 5 years 12 mons 5 days 6 hours
>
>
>
> Doesn't this look odd regardless of what bad results come back from the
> FP library?
The problem was generated, because -fast option was set only for the
compiler and not for the linker. Linker takes wrong version of
libraries. If -fast is set for both then horology test is OK, but
question was if float optimalization should generate some problems.
regards, Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-27 13:49:26 | Re: Faster StrNCpy |
Previous Message | Andrew Dunstan | 2006-09-27 13:22:30 | Re: Faster StrNCpy |