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

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
   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
   SSE instructions?

   As things seems to work at -O0, but not at -On (with n > 0), it is
   unlikely that runtime-functions itself are causing this issue. So
   therefore my guess goes here for internal/external precision of used



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to