Hi,
during tests with my mingw builds variant mingw-w64-for-python
<https://bitbucket.org/carlkl/mingw-w64-for-python/downloads> I stumpled
upon a flaw in mingw-w64 FPU handling on startup. This is issued at
mingw-w64 builds of numpy <https://github.com/numpy/numpy/issues/5194> and test
failures when building win32 binaries with mingw based on gcc 4.8
<https://github.com/numpy/numpy/issues/4909>. The reason for this
behaviour: CRT_fp10.o (part of libmingw32.a) sets the FPU control word to
extended precision on startup as per default. This can be overwritten by
additionally linking CRT_fp8.o, but this is documented elsewhere
(floath.h). As far I can see, this behaviour in mingw-w64 inherits from the
Mingw32 codebase, but I'm not sure.
There seems to be a consense, that 027f should be the standard for setting
the FPU control word. Otherwise it gets into your way, see i.e. Random and
unexpected EXCEPTION_FLT_DIVIDE_BY_ZERO and EXCEPTION_FLT_INVALID__OPERATION
<http://blogs.msdn.com/b/dougste/archive/2008/11/12/random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx>
Is there some code in mingw.w64 that depends on extended precision as a
default value? Otherwise this should be fixed in the mingw-w64 codebase
IMHO.
Regards
Carl
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
