Re: [Mingw-w64-public] FPU control word on startup
2014-11-26 3:28 GMT+01:00 Dongsheng Song dongsheng.s...@gmail.com: On 2014-11-26 04:58, Kai Tietz wrote: 2014-11-25 21:49 GMT+01:00 Carl Kleffner cmkleff...@gmail.com: 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 Yes, we can do here something. Question is here the following: Do we want to do this only if executable is generated by mingw-w64, or do we want it for each loaded DLL? Kai It's really strange thing, can we just set to extended precision in the function pthread_create ? Regards, Cauchy Well, to set it just for pthread_create would be too short. Well, we might consider to add too our pthread-code the ability to clone creator-thread's FPU-control-word to its child-thread, but this seems to me like a different story. I think that the proper behavior is to set FPU-control-word for any thread within an application using our startup. So we won't set it within DLLs explicit, but just in EXEs. Kai -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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 pthread.h
#include stdio.h
void *thread_fun(void *x_void_ptr)
{
printf(thread\n);
return NULL;
}
int main()
{
pthread_t thread;
if(pthread_create(thread, NULL, thread_fun, NULL)) {
fprintf(stderr, Error creating thread\n);
return 1;
}
if(pthread_join(thread, NULL)) {
fprintf(stderr, Error joining thread\n);
return 2;
}
return 0;
}
// (gdb) break main
// Breakpoint 1 at 0x40157c
// (gdb) break thread_fun
// Breakpoint 2 at 0x401566
// (gdb) r
// Starting program: a.exe
// [New Thread 5832.0x7c8]
//
// Breakpoint 1, 0x0040157c in main ()
// (gdb) p $fctrl
// $1 = 895
// (gdb) c
// Continuing.
// [New Thread 5832.0xf10]
// [Switching to Thread 5832.0xf10]
//
// Breakpoint 2, 0x00401566 in thread_fun ()
// (gdb) p $fctrl
// $2 = 639
// (gdb) c
Is there a way to get around of this?
2014-11-24 21:30 GMT+01:00 Kai Tietz ktiet...@googlemail.com:
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 explicit for 64-bit precision by
different object-files, as already noted in this thread (CRT_fp8,
CRT_fp10,...). This is the same as for txtmode.o vs. binmode.o, or
CRT_noglob.o vs. CRT_glob.o changing behavior.
Nevertheless I would welcome if someone would contribute a good page
on our Wiki FAQ-section.
Regards,
Kai
--
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=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
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=157005751iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
2014-11-25 21:49 GMT+01:00 Carl Kleffner cmkleff...@gmail.com:
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 pthread.h
#include stdio.h
void *thread_fun(void *x_void_ptr)
{
printf(thread\n);
return NULL;
}
int main()
{
pthread_t thread;
if(pthread_create(thread, NULL, thread_fun, NULL)) {
fprintf(stderr, Error creating thread\n);
return 1;
}
if(pthread_join(thread, NULL)) {
fprintf(stderr, Error joining thread\n);
return 2;
}
return 0;
}
// (gdb) break main
// Breakpoint 1 at 0x40157c
// (gdb) break thread_fun
// Breakpoint 2 at 0x401566
// (gdb) r
// Starting program: a.exe
// [New Thread 5832.0x7c8]
//
// Breakpoint 1, 0x0040157c in main ()
// (gdb) p $fctrl
// $1 = 895
// (gdb) c
// Continuing.
// [New Thread 5832.0xf10]
// [Switching to Thread 5832.0xf10]
//
// Breakpoint 2, 0x00401566 in thread_fun ()
// (gdb) p $fctrl
// $2 = 639
// (gdb) c
Is there a way to get around of this?
2014-11-24 21:30 GMT+01:00 Kai Tietz ktiet...@googlemail.com:
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 explicit for 64-bit precision by
different object-files, as already noted in this thread (CRT_fp8,
CRT_fp10,...). This is the same as for txtmode.o vs. binmode.o, or
CRT_noglob.o vs. CRT_glob.o changing behavior.
Nevertheless I would welcome if someone would contribute a good page
on our Wiki FAQ-section.
Regards,
Kai
--
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=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Yes, we can do here something. Question is here the following: Do we
want to do this only if executable is generated by mingw-w64, or do we
want it for each loaded DLL?
Kai
--
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=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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. Unfortunately this is not garenteed by the CRT
(blame Windows or me if I missed something). New threads seems to start
with default values. Should be documented.
2014-11-25 21:58 GMT+01:00 Kai Tietz ktiet...@googlemail.com:
2014-11-25 21:49 GMT+01:00 Carl Kleffner cmkleff...@gmail.com:
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 pthread.h
#include stdio.h
void *thread_fun(void *x_void_ptr)
{
printf(thread\n);
return NULL;
}
int main()
{
pthread_t thread;
if(pthread_create(thread, NULL, thread_fun, NULL)) {
fprintf(stderr, Error creating thread\n);
return 1;
}
if(pthread_join(thread, NULL)) {
fprintf(stderr, Error joining thread\n);
return 2;
}
return 0;
}
// (gdb) break main
// Breakpoint 1 at 0x40157c
// (gdb) break thread_fun
// Breakpoint 2 at 0x401566
// (gdb) r
// Starting program: a.exe
// [New Thread 5832.0x7c8]
//
// Breakpoint 1, 0x0040157c in main ()
// (gdb) p $fctrl
// $1 = 895
// (gdb) c
// Continuing.
// [New Thread 5832.0xf10]
// [Switching to Thread 5832.0xf10]
//
// Breakpoint 2, 0x00401566 in thread_fun ()
// (gdb) p $fctrl
// $2 = 639
// (gdb) c
Is there a way to get around of this?
2014-11-24 21:30 GMT+01:00 Kai Tietz ktiet...@googlemail.com:
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 explicit for 64-bit precision by
different object-files, as already noted in this thread (CRT_fp8,
CRT_fp10,...). This is the same as for txtmode.o vs. binmode.o, or
CRT_noglob.o vs. CRT_glob.o changing behavior.
Nevertheless I would welcome if someone would contribute a good page
on our Wiki FAQ-section.
Regards,
Kai
--
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=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Yes, we can do here something. Question is here the following: Do we
want to do this only if executable is generated by mingw-w64, or do we
want it for each loaded DLL?
Kai
--
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=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
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=157005751iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
On 2014-11-26 04:58, Kai Tietz wrote: 2014-11-25 21:49 GMT+01:00 Carl Kleffner cmkleff...@gmail.com: 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 Yes, we can do here something. Question is here the following: Do we want to do this only if executable is generated by mingw-w64, or do we want it for each loaded DLL? Kai It's really strange thing, can we just set to extended precision in the function pthread_create ? Regards, Cauchy smime.p7s Description: S/MIME Cryptographic Signature -- 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=157005751iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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 possible with MSVC). Nevertheless I suggest double computation precision should be the default and extended double computation precision an option. Silently change the FPU settings can cause bad side effects (see the link on my first posting). 2014-11-23 17:39 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: 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 computation accuracy to 0x27f. The 'long double' size incompatibility requires mingw to implement various long-double functions including printf and scanf, independently of MSVCRT. So the decision is whether long doubles should be 64 or 80 bits. The control word is simply the result of this decision. BTW. see Kahan about long doubles (in Java, though), http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf 2014-11-23 18:03 GMT+02:00 Carl Kleffner cmkleff...@gmail.com: 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 all floating-point exceptions, sets rounding to nearest, and sets the x87 FPU precision to 64 bits. That is 80-bit double extended computation precision as default and definitly not the expected double computation precision. See also: http://sourceforge.net/p/mingw/bugs/904/ https://ghc.haskell.org/trac/ghc/ticket/7289 Carl 2014-11-23 10:52 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: 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 FPU computation precision regardless the external representation size. 3 The exceptions Carl refers are disabled by setting the _MCW_EM mask, mostly 0x1F of the 0x27F mentioned. This is independent the computation precision or long double size. see also http://www.exploringbinary.com/when-doubles-dont-behave-like-doubles/ 2014-11-23 11:08 GMT+02:00 Kai Tietz ktiet...@googlemail.com: 2014-11-23 9:17 GMT+01:00 Ozkan Sezer seze...@gmail.com: 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. Well, there is AFAIK. We have the 'long double' support, which is actually using 80-bit extended-mode x87 FPU, So, not sure if need to keep it for this. Kai -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list
Re: [Mingw-w64-public] FPU control word on startup
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 cmkleff...@gmail.com wrote: 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 80-bit long doubles are hardly outdated. Many people use them and rely on them. and non portable. That's quite a specious argument, given x86 (and other) support for 80-bit precision dating back to the 8087. Sure, hardware support for 80-bit doubles is not portable across all platforms (nor is support for 64-bit doubles, nor for 32-bit doubles, etc., etc.), but that's no reason to make mingw-w64 run suboptimally on very widespread hardware. The article by Kahan that Yaron linked to makes a very good argument (in the context of java) that exact compatibility / portability is a bad idea (and an illusory goal in any event). (He also has a few choice words about Microsoft's bad choice on this issue, as well he should.) It is just fine to have the possibilty to use 80bit longs doubles if needed (not possible with MSVC). Nevertheless I suggest double computation precision should be the default and extended double computation precision an option. Silently change the FPU settings can cause bad side effects (see the link on my first posting). Although polemical in tone, Kahan's explains things very well. Not using extended precision is sufficiently worse than using it that not doing so can be considered wrong. So, if Microsoft had a sqrt function that gave sqrt(16) == 5, would you ask that mingw-w64 do the same in the name of compatibility with Microsoft? On common modern hardware, float is 32 bits, double is 64 bits, and common modern hardware supports 80-bit doubles. long double is a different type from double. Why force long double and double to be the same 64 bits, when 80 bits is supported by hardware? You want 64 bits, use double. I want 80 bits, I'll use long double. Why make it hard (or impossible) for me to use 80-bit long doubles just because you want 64-bit doubles even if you accidentally type long double? Read Kahan. He is absolutely an expert in this kind of thing (and has been making these kind of arguments since before I was born, which is saying something). Mingw-w64 has the choice of doing what Microsoft does, or following Kahan's recommendation. Given that choice, it's Kahan, hands down. Trust me -- if you become an expert on numerical analysis and floating-point computation, you will agree with Kahan. But you don't need to become an expert -- just follow the experts' advice. (And if the experts' advice differs from what Microsoft and python and java, etc., etc. do, follow the experts' advice anyways.) 2014-11-23 17:39 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: 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 computation accuracy to 0x27f. The 'long double' size incompatibility requires mingw to implement various long-double functions including printf and scanf, independently of MSVCRT. So the decision is whether long doubles should be 64 or 80 bits. The control word is simply the result of this decision. BTW. see Kahan about long doubles (in Java, though), http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf Thank you Yaron -- this is an excellent reference. It's well worth reading (as is most anything by Kahan). Happy Floating-Point Hacking! K. Frank -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx http://blogs.msdn.com/b/dougste/archive/2008/11/12/random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx or https://github.com/numpy/numpy/issues/5194 . At least it is a matter of documentation. I would like to ask you for an item in the mingw-w64 FAQ to explain the difference between the settings and how to choose double precision instead (linking CRT_fp8.o AFAIK) Cheers, Carl 2014-11-24 15:01 GMT+01:00 K. Frank kfrank2...@gmail.com: 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 cmkleff...@gmail.com wrote: 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 80-bit long doubles are hardly outdated. Many people use them and rely on them. and non portable. That's quite a specious argument, given x86 (and other) support for 80-bit precision dating back to the 8087. Sure, hardware support for 80-bit doubles is not portable across all platforms (nor is support for 64-bit doubles, nor for 32-bit doubles, etc., etc.), but that's no reason to make mingw-w64 run suboptimally on very widespread hardware. The article by Kahan that Yaron linked to makes a very good argument (in the context of java) that exact compatibility / portability is a bad idea (and an illusory goal in any event). (He also has a few choice words about Microsoft's bad choice on this issue, as well he should.) It is just fine to have the possibilty to use 80bit longs doubles if needed (not possible with MSVC). Nevertheless I suggest double computation precision should be the default and extended double computation precision an option. Silently change the FPU settings can cause bad side effects (see the link on my first posting). Although polemical in tone, Kahan's explains things very well. Not using extended precision is sufficiently worse than using it that not doing so can be considered wrong. So, if Microsoft had a sqrt function that gave sqrt(16) == 5, would you ask that mingw-w64 do the same in the name of compatibility with Microsoft? On common modern hardware, float is 32 bits, double is 64 bits, and common modern hardware supports 80-bit doubles. long double is a different type from double. Why force long double and double to be the same 64 bits, when 80 bits is supported by hardware? You want 64 bits, use double. I want 80 bits, I'll use long double. Why make it hard (or impossible) for me to use 80-bit long doubles just because you want 64-bit doubles even if you accidentally type long double? Read Kahan. He is absolutely an expert in this kind of thing (and has been making these kind of arguments since before I was born, which is saying something). Mingw-w64 has the choice of doing what Microsoft does, or following Kahan's recommendation. Given that choice, it's Kahan, hands down. Trust me -- if you become an expert on numerical analysis and floating-point computation, you will agree with Kahan. But you don't need to become an expert -- just follow the experts' advice. (And if the experts' advice differs from what Microsoft and python and java, etc., etc. do, follow the experts' advice anyways.) 2014-11-23 17:39 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: 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 computation accuracy to 0x27f. The 'long double' size incompatibility requires mingw to implement various long-double functions including printf and scanf, independently of MSVCRT. So the decision is whether long doubles should be 64 or 80 bits. The control word is simply the result of this decision. BTW. see Kahan about long doubles (in Java, though), http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf Thank you Yaron -- this is an excellent reference. It's well worth reading (as is most anything by Kahan). Happy Floating-Point Hacking! K. Frank -- 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
Re: [Mingw-w64-public] FPU control word on startup
Hello Carl! On Mon, Nov 24, 2014 at 9:55 AM, Carl Kleffner cmkleff...@gmail.com 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 doubles, as it affects double precision computation. Yes,to clarify my earlier comments: It is correct that even if you use regular 64-bit doubles, the (x87-style) floating-point hardware will (in extended-precision mode) compute intermediate results with 80-bit precision as long as the computations stay in the floating-point registers, and only round them down to 64-bit doubles when they are written to memory. And yes, this can give different (almost always better) results than computing intermediate results with 64-bit precision. So, yes, this will be incompatible with (but generally better than) the Microsoft approach, even when only using doubles (i.e., not long doubles). See random-and-unexpected-exception-flt-divide-by-zero-and-exception-flt-invalid-operation.aspx or https://github.com/numpy/numpy/issues/5194 . At least it is a matter of documentation. I would like to ask you for an item in the mingw-w64 FAQ to explain the difference between the settings and how to choose double precision instead (linking CRT_fp8.o AFAIK) Yes, very reasonable. Whatever default behavior Kai Co. choose for mingw-w64, it should of course be documented, and, if different than the Microsoft approach, that difference should be highlighted. And, of course, the end-user should be able to override the default behavior, whether it's me who wants 80-precision for intermediate results, or someone like yourself who has a use-case where 64-bit intermediate results are desired. (Don't get me wrong -- I do believe that there are legitimate use-cases for using 64-bit precision for intermediate results. I just think they're rare.) (I, of course, would vote for the default to be 80-bit long doubles with 80-bit precision for intermediate results based on my own experience, but, much more importantly, based on the recommendation of the experts such as Kahan. But I would also vote for giving the end-user properly documented mechanisms to override the default.) Cheers, Carl Best. Happy Extended-Precision Floating-Point Hacking! K. Frank ... 2014-11-24 15:01 GMT+01:00 K. Frank kfrank2...@gmail.com: Hi Carl! I very much think that 80 bits should be the default for long doubles, even if Microsoft does differently. ... -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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 explicit for 64-bit precision by different object-files, as already noted in this thread (CRT_fp8, CRT_fp10,...). This is the same as for txtmode.o vs. binmode.o, or CRT_noglob.o vs. CRT_glob.o changing behavior. Nevertheless I would welcome if someone would contribute a good page on our Wiki FAQ-section. Regards, Kai -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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 FPU computation precision regardless the external representation size. 3 The exceptions Carl refers are disabled by setting the _MCW_EM mask, mostly 0x1F of the 0x27F mentioned. This is independent the computation precision or long double size. see also http://www.exploringbinary.com/when-doubles-dont-behave-like-doubles/ 2014-11-23 11:08 GMT+02:00 Kai Tietz ktiet...@googlemail.com: 2014-11-23 9:17 GMT+01:00 Ozkan Sezer seze...@gmail.com: 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. Well, there is AFAIK. We have the 'long double' support, which is actually using 80-bit extended-mode x87 FPU, So, not sure if need to keep it for this. Kai -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- 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=157005751iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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 all floating-point exceptions, sets rounding to nearest, and sets the x87 FPU precision to 64 bits. That is 80-bit double extended computation precision as default and definitly not the expected double computation precision. See also: http://sourceforge.net/p/mingw/bugs/904/ https://ghc.haskell.org/trac/ghc/ticket/7289 Carl 2014-11-23 10:52 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: 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 FPU computation precision regardless the external representation size. 3 The exceptions Carl refers are disabled by setting the _MCW_EM mask, mostly 0x1F of the 0x27F mentioned. This is independent the computation precision or long double size. see also http://www.exploringbinary.com/when-doubles-dont-behave-like-doubles/ 2014-11-23 11:08 GMT+02:00 Kai Tietz ktiet...@googlemail.com: 2014-11-23 9:17 GMT+01:00 Ozkan Sezer seze...@gmail.com: 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. Well, there is AFAIK. We have the 'long double' support, which is actually using 80-bit extended-mode x87 FPU, So, not sure if need to keep it for this. Kai -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- 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=157005751iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] FPU control word on startup
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 computation accuracy to 0x27f. The 'long double' size incompatibility requires mingw to implement various long-double functions including printf and scanf, independently of MSVCRT. So the decision is whether long doubles should be 64 or 80 bits. The control word is simply the result of this decision. BTW. see Kahan about long doubles (in Java, though), http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf 2014-11-23 18:03 GMT+02:00 Carl Kleffner cmkleff...@gmail.com: 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 all floating-point exceptions, sets rounding to nearest, and sets the x87 FPU precision to 64 bits. That is 80-bit double extended computation precision as default and definitly not the expected double computation precision. See also: http://sourceforge.net/p/mingw/bugs/904/ https://ghc.haskell.org/trac/ghc/ticket/7289 Carl 2014-11-23 10:52 GMT+01:00 Yaron Keren yaron.ke...@gmail.com: 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 FPU computation precision regardless the external representation size. 3 The exceptions Carl refers are disabled by setting the _MCW_EM mask, mostly 0x1F of the 0x27F mentioned. This is independent the computation precision or long double size. see also http://www.exploringbinary.com/when-doubles-dont-behave-like-doubles/ 2014-11-23 11:08 GMT+02:00 Kai Tietz ktiet...@googlemail.com: 2014-11-23 9:17 GMT+01:00 Ozkan Sezer seze...@gmail.com: 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. Well, there is AFAIK. We have the 'long double' support, which is actually using 80-bit extended-mode x87 FPU, So, not sure if need to keep it for this. Kai -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- 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=157005751iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list
