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'toccure with x64 version, which uses sse instructions instead of x87) is that x87 registers internally have
higherprecision then 32-bit. So failures in range occure on conversion from FPU register down to memory store. For
x64SSE this is different, as here math operations are really just done in specified precission. Have you checked,
ifyou 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
arecausing this issue. So therefore my guess goes here for internal/external precision of used FPU.
cheers
andrew
