On 12/14/2011 04:43 AM, Mark Cave-Ayland wrote:
On 12/12/11 15:00, Andrew Dunstan wrote:
Yeah, fair enough. I'll work on that.
If we're talking about adding support for a previously-unsupported
Definitely do this (and then file a bug report with the project). I've
worked with both Kai and NightStrike from the MingW-W64 project to fix
previous bugs, and as long as they can build the offending source
themselves then they are very helpful and quick to respond.
Done and done (see
<https://sourceforge.net/tracker/?func=detail&aid=3458244&group_id=202880&atid=983354>).
Hi Andrew,
Did you see Kai's update on the ticket? If this is the case, I know
that we have seen similar bugs with PostGIS and the work-around has
been to add -ffloat-store to the compiler flags for the affected files
if that helps?
Hmm. Yeah, if I remove -O0 and instead set CFLAGS to -ffloat-store the
error goes away.
So, would we want to use that just for this file, or for the whole build?
FTR, the comment in the bug reads:
AFAICS from report, the issue happens with value 1e200 (as invalid
range).
The issue I might see here (as it doesn't occure with x64 version, which
uses sse instructions instead of x87) is that x87 registers
internally have
higher precision then 32-bit. So failures in range occure on conversion
from FPU register down to memory store. For x64 SSE this is
different, as
here math operations are really just done in specified precission.
Have you checked, if you get different result by using on 32-bit
explicit
SSE instructions?
As things seems to work at -O0, but not at -On (with n > 0), it is
pretty
unlikely that runtime-functions itself are causing this issue. So
therefore my guess goes here for internal/external precision of used
FPU.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
