On 11/12/14, Carl Kleffner <cmkleff...@gmail.com> wrote: > 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
PING ? -- O.S. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
