Re: [Mingw-w64-public] FPU control word on startup

2014-11-26 Thread Kai Tietz
2014-11-26 3:28 GMT+01:00 Dongsheng Song : > On 2014-11-26 04:58, Kai Tietz wrote: >> >> 2014-11-25 21:49 GMT+01:00 Carl Kleffner : >>> >>> Hi Kai, >>> >>> you may take notice of some inconsistent behaviour. The master thread >>> starts >>> with extended precision. Newly created threads start with

Re: [Mingw-w64-public] FPU control word on startup

2014-11-25 Thread Dongsheng Song
On 2014-11-26 04:58, Kai Tietz wrote: 2014-11-25 21:49 GMT+01:00 Carl Kleffner : Hi Kai, you may take notice of some inconsistent behaviour. The master thread starts with extended precision. Newly created threads start with the MSVC standard double precision. https://bugs.debian.org/cgi-bin/bu

Re: [Mingw-w64-public] FPU control word on startup

2014-11-25 Thread Carl Kleffner
Him Rule thumb 1: A callee should not NEVER affect the FPU setting of the caller. If a different setting is necessary, it should be switched back before return. Is this the case for mingw-w64 DLLs? Rule thumb 2: If main is created by mingw-w64 the thread should inherit the setting from the caller

Re: [Mingw-w64-public] FPU control word on startup

2014-11-25 Thread Kai Tietz
2014-11-25 21:49 GMT+01:00 Carl Kleffner : > Hi Kai, > > you may take notice of some inconsistent behaviour. The master thread starts > with extended precision. Newly created threads start with the MSVC standard > double precision. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761175 > > #i

Re: [Mingw-w64-public] FPU control word on startup

2014-11-25 Thread Carl Kleffner
Hi Kai, you may take notice of some inconsistent behaviour. The master thread starts with extended precision. Newly created threads start with the MSVC standard double precision. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761175 #include #include void *thread_fun(void *x_void_ptr) {

Re: [Mingw-w64-public] FPU control word on startup

2014-11-24 Thread Kai Tietz
Hello, so from my POV decision is already made. 80-bit support is wanted, and needs to be active for being compatible with C99-math and testsuites and gcc for Windows. This support for 64-bit goes back to 2005, and for 32-bit even much earlier (1998 ?). We provide a way for users asking explici

Re: [Mingw-w64-public] FPU control word on startup

2014-11-24 Thread K. Frank
Hello Carl! On Mon, Nov 24, 2014 at 9:55 AM, Carl Kleffner wrote: > Hi K.Frank > > It's absolutely your (community) choice of course and fairly unproblematic > if you stay inside the mingw-w64 system. > > It is however incompatible for MSVC compatibility even in case you never > touch long double

Re: [Mingw-w64-public] FPU control word on startup

2014-11-24 Thread Carl Kleffner
Hi K.Frank It's absolutely your (community) choice of course and fairly unproblematic if you stay inside the mingw-w64 system. It is however incompatible for MSVC compatibility even in case you never touch long doubles, as it affects double precision computation. See random-and-unexpected-excepti

Re: [Mingw-w64-public] FPU control word on startup

2014-11-24 Thread K. Frank
Hi Carl! I very much think that 80 bits should be the default for long doubles, even if Microsoft does differently. On Mon, Nov 24, 2014 at 3:57 AM, Carl Kleffner wrote: > I don't see the point, why computation accuracy has to be set to 0x37f per > default. Usually computations are done with sin

Re: [Mingw-w64-public] FPU control word on startup

2014-11-24 Thread Carl Kleffner
I don't see the point, why computation accuracy has to be set to 0x37f per default. Usually computations are done with single or double precision today. Using 80bit long double precision is outdated and non portable. It is just fine to have the possibilty to use 80bit longs doubles if needed (not p

Re: [Mingw-w64-public] FPU control word on startup

2014-11-23 Thread Yaron Keren
It is a real incompatibility between VC and mingw. Visual C++ dropped support for 80 bit long doubles on x87 many years ago, in VC long doubles are 64 bit, which is why they use 0x27F. mingw still supports 80 long doubles on x87. As long this is the case, it is incosistent for mingw to set computat

Re: [Mingw-w64-public] FPU control word on startup

2014-11-23 Thread Carl Kleffner
What I'm talking about ist the following: CRT_fp10.o on startup executes FNINIT. According to http://www.intel.com/Assets/ja_JP/PDF/manual/253665.pdf: "When the x87 FPU is initialized with either an FINIT/FNINIT or FSAVE/FNSAVE instruction, the x87 FPU control word is set to 037FH, which masks al

Re: [Mingw-w64-public] FPU control word on startup

2014-11-23 Thread Yaron Keren
http://msdn.microsoft.com/en-us/library/e9b52ceh.aspx I think three issues are conflated: 1 long double size is 80 bits in mingw and 64 bits in VC. 2 The mask 0x27F will set the 80-bit extended computation precision, _PC_64 (64/80) and not _PC_53 (53/64) computation precision. This is internal F

Re: [Mingw-w64-public] FPU control word on startup

2014-11-23 Thread Kai Tietz
2014-11-23 9:17 GMT+01:00 Ozkan Sezer : > On 11/12/14, Carl Kleffner wrote: >> Hi, >> >> during tests with my mingw builds variant mingw-w64-for-python >> I stumpled >> upon a flaw in mingw-w64 FPU handling on startup. This is issued at

Re: [Mingw-w64-public] FPU control word on startup

2014-11-23 Thread Ozkan Sezer
On 11/12/14, Carl Kleffner wrote: > Hi, > > during tests with my mingw builds variant mingw-w64-for-python > I stumpled > upon a flaw in mingw-w64 FPU handling on startup. This is issued at > mingw-w64 builds of numpy