Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[JonY]

On 3/15/2016 23:15, Benjamin Bihler wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset
> thread floating point settings on new thread") from the master branch
> of the mingw64 repository, compiled it and replaced the respective
> files in the "include" and "lib" folder of the "x86_64-mingw32"
> folder of my mingww64 5.3.0 installation with the newly compiled
> files.
> 
> Then I have compiled my sample file with this modified mingw64
> installation. It had no effect, the two threads give different
> results. I have checked that the executable depends only on the DLLs
> Kernel32.dll and Msvcrt.dll.
> 
> When I add
> 
> _fpreset()
> 
> as the first command of the method that is run asynchronously, both
> threads give the same result. But this has already been the case with
> the unmodified mingw64 compiler (without overwriting the link
> binaries with those from the new revision), I have checked that.
> 
> My sample is a C++ sample, since I am using the gnu++11 features.
> 
> It would be painful for me, if I had to add _fpreset() to all methods
> that I want to run asynchronously, especially since they may be part
> of other libraries.
> 
> Did I patch my mingw64 installation in a wrong way? Otherwise it
> seems as if the commit mentioned above does not solve my problem.
> 
> Does anyone have another idea? Thanks!


Hi,

Can you try with the latest code? I have just moved the _fpreset call,
hopefully it gets called correctly this time.


0xD4EBC740.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

Thank you for the suggestion.

I have tried the following code snippets when the program starts up to set the 
floating-point precision:

---
unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_24, _MCW_PC);
---

---
unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_53, _MCW_PC);
---

---
unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_64, _MCW_PC);
---

This does not help. Still the asynchronous thread gives different results. 
Should I use different commands? Which ones?

Actually limiting the fp precision on the main thread would be a solution for 
me, though it feels like a dirty workaround.

-Ursprüngliche Nachricht-
Von: K. Frank [mailto:kfrank2...@gmail.com] 
Gesendet: Dienstag, 15. März 2016 22:09
An: mingw64
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

Hi Benjamin!

I have no idea how to patch mingw-w64 to do you you really want, but perhaps I 
have a suggestion for a work-around, below.

On Tue, Mar 15, 2016 at 11:15 AM, Benjamin Bihler 
<benjamin.bih...@compositence.de> wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset thread 
> floating point settings on new thread") from the master branch of the mingw64 
> repository, compiled it and replaced the respective files in the "include" 
> and "lib" folder of the "x86_64-mingw32" folder of my mingww64 5.3.0 
> installation with the newly compiled files.
>
> Then I have compiled my sample file with this modified mingw64 installation. 
> It had no effect, the two threads give different results. I have checked that 
> the executable depends only on the DLLs Kernel32.dll and Msvcrt.dll.
>
> When I add
>
> _fpreset()
>
> as the first command of the method that is run asynchronously, both threads 
> give the same result. But this has already been the case with the unmodified 
> mingw64 compiler (without overwriting the link binaries with those from the 
> new revision), I have checked that.
>
> My sample is a C++ sample, since I am using the gnu++11 features.
>
> It would be painful for me, if I had to add _fpreset() to all methods that I 
> want to run asynchronously, especially since they may be part of other 
> libraries.
>
> Did I patch my mingw64 installation in a wrong way? Otherwise it seems as if 
> the commit mentioned above does not solve my problem.
>
> Does anyone have another idea? Thanks!

Disclaimer: I don't know anything about the patch or the _fpreset() call.  
Also, I am speaking from memory, so I may have some of the details backwards.

Is it essential that you get the better, 80-bit long-double behavior, or can 
you live with 64-bit long doubles as long as all threads behave the same way?

As I understand it, the main thread starts with the 80-bit setting, but 
somebody (mingw?, microsoft?) sets 64-bit behavior on start-up of subsequent 
threads.

Perhaps you could -- just once, in your main thread -- set the 64-bit behavior 
when your program starts up.  Then (hopefully) all new threads that 
automatically get 64-bit behavior will match your main thread.

You would still have to call some sort of "_fpset(...)" once in your main 
thread, but you would no longer have to add _fpreset to all of your 
asynchronous methods.

(You might have to do some reverse engineering or ask on this list to find out 
exactly what floating-point mode you need to set for your main thread in order 
that it match that of the child treads.)

Sorry if this is all nonsense, but maybe it could help.


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics 
Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

Hi Kai,

I am a complete novice when it comes to patching Mingw. I have done the 
following:


-  Cloned git://git.code.sf.net/p/mingw-w64/mingw-w64

-  mkdir build

-  cd build

-  ../mingw-w64-crt/configure --prefix=/d/OpenCascade/mingw-w64-install 
--host=x86_64-w64-mingw32

-  make all

-  make install

-  copied the files from /d/OpenCascade/mingw-w64-install/include and 
/d/OpenCascade/mingw-w64-install/lib to the respective folders in the 
x86_64-w64-mingw32 folder of my Mingw-w64 installation

Is this “building a replaced complete runtime”? If not, how can I do that?

Thank you very much!
Benjamin

Von: Kai Tietz [mailto:ktiet...@googlemail.com]
Gesendet: Dienstag, 15. März 2016 22:24
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously


Hi Benjamin,

I would assume that there might be something wrong with your update of crt.  
What doesn't get clear to me by your description is what you build and what you 
replaced actually.
The code in question is part of the crt build .a files. have you just replace 
object code (as it sounds) or have you build an replaced complete runtime?

Kai
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

There is no difference in the results. I have even raised the precision of the 
number output, but my call to _controlfp_s seems not to influence the output at 
all... what does that mean? That _controlfp_s cannot be a part of the solution?

-Ursprüngliche Nachricht-
Von: K. Frank [mailto:kfrank2...@gmail.com] 
Gesendet: Donnerstag, 17. März 2016 14:40
An: mingw64
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler 
<benjamin.bih...@compositence.de> wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do have a 
debugging question.

Did any of your versions of calling _controlfp_s have any effect in that they 
changed the results produced by the main thread (even if those changed results 
did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s 
call?

Obviously, until you can change the behavior of the main thread, you can't 
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to 
_controlfp_s you need to match the floating-point environment that is getting 
set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's the 
nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any detail 
on how to make it work.

(Of course, the better approach is to figure out how to make the child threads 
behave -- i.e., use the extended precision, and otherwise use a floating-point 
environment consistent with that of the main thread.)


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics 
Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[K. Frank]

Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler
 wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do
have a debugging question.

Did any of your versions of calling _controlfp_s have any effect in that
they changed the results produced by the main thread (even if those
changed results did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s
call?

Obviously, until you can change the behavior of the main thread, you can't
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to
_controlfp_s you need to match the floating-point environment that is
getting set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's
the nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any
detail on how to make it work.

(Of course, the better approach is to figure out how to make the child
threads behave -- i.e., use the extended precision, and otherwise use
a floating-point environment consistent with that of the main thread.)


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Carl Kleffner]

Just link your example with CRT_Fp8.o:

g++ -O2 -std=gnu++11 main.cpp
\mingw64\x86_64-w64-mingw32\lib\CRT_fp8.o

With that it is ensured that the intermediate precision of the FPU is
double precision even for the main thread. In the C99 standard this is
FLT_EVAL_METHOD=1

The problem with mingw-w64 is that it defaults to FLT_EVAL_METHOD=2
(intermediate precision is long double), but new threads never starts with
FLT_EVAL_METHOD=2  per default on Windows. Hence the difference between
main thread and new thread.

C.

2016-03-17 15:45 GMT+01:00 Benjamin Bihler <benjamin.bih...@compositence.de>
:

> There is no difference in the results. I have even raised the precision of
> the number output, but my call to _controlfp_s seems not to influence the
> output at all... what does that mean? That _controlfp_s cannot be a part of
> the solution?
>
> -Ursprüngliche Nachricht-
> Von: K. Frank [mailto:kfrank2...@gmail.com]
> Gesendet: Donnerstag, 17. März 2016 14:40
> An: mingw64
> Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not
> Deterministic When Excecuted Asynchronously
>
> Hi Benjamin!
>
> On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler <
> benjamin.bih...@compositence.de> wrote:
> > Thank you for the suggestion.
> >
> > I have tried the following code snippets when the program starts up to
> set the floating-point precision:
> >
> > ---
> > unsigned int fpu_cw;
> >  _controlfp_s(_cw, _PC_24, _MCW_PC);
> > ---
> > ...
> > This does not help. Still the asynchronous thread gives different
> results. Should I use different commands? Which ones?
>
> I don't know anything about the details of _controlfp_s, etc., but I do
> have a debugging question.
>
> Did any of your versions of calling _controlfp_s have any effect in that
> they changed the results produced by the main thread (even if those changed
> results did not match the results of the asynchronous thread)?
>
> Or did your main thread still give the same results as without the
> _controlfp_s call?
>
> Obviously, until you can change the behavior of the main thread, you can't
> change it to match the asynchronous threads.
>
> In any event, hopefully someone on this list could tell you what call to
> _controlfp_s you need to match the floating-point environment that is
> getting set up for the asynchronous thread.  (I certainly can't.)
>
> > Actually limiting the fp precision on the main thread would be a
> solution for me, though it feels like a dirty workaround.
>
> Yeah, you shouldn't have to use the less-favorable precision.  But that's
> the nature of work-arounds ...
>
> Logically, I do think the idea should work.  Sorry i can't give you any
> detail on how to make it work.
>
> (Of course, the better approach is to figure out how to make the child
> threads behave -- i.e., use the extended precision, and otherwise use a
> floating-point environment consistent with that of the main thread.)
>
>
> Good luck.
>
>
> K. Frank
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with Intel Data Analytics
> Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

Thank you for that hint! Now really the two threads behave equally! ☺

How to continue? Is it a disadvantage to default to FLT_EVAL_METHOD=1 with 
mingw-w64? Will the fix be part of the next mingw-w64 release? Then with the 
new compiler distribution, my thread will behave the same without linking to 
extra fp-related objects?
Thanks for answers and support!

Von: Carl Kleffner [mailto:cmkleff...@gmail.com]
Gesendet: Donnerstag, 17. März 2016 16:09
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

Just link your example with CRT_Fp8.o:

g++ -O2 -std=gnu++11 main.cpp \mingw64\x86_64-w64-mingw32\lib\CRT_fp8.o
With that it is ensured that the intermediate precision of the FPU is double 
precision even for the main thread. In the C99 standard this is 
FLT_EVAL_METHOD=1
The problem with mingw-w64 is that it defaults to FLT_EVAL_METHOD=2 
(intermediate precision is long double), but new threads never starts with 
FLT_EVAL_METHOD=2  per default on Windows. Hence the difference between main 
thread and new thread.
C.

2016-03-17 15:45 GMT+01:00 Benjamin Bihler 
<benjamin.bih...@compositence.de<mailto:benjamin.bih...@compositence.de>>:
There is no difference in the results. I have even raised the precision of the 
number output, but my call to _controlfp_s seems not to influence the output at 
all... what does that mean? That _controlfp_s cannot be a part of the solution?

-Ursprüngliche Nachricht-
Von: K. Frank [mailto:kfrank2...@gmail.com<mailto:kfrank2...@gmail.com>]
Gesendet: Donnerstag, 17. März 2016 14:40
An: mingw64
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously
Hi Benjamin!

On Thu, Mar 17, 2016 at 4:07 AM, Benjamin Bihler 
<benjamin.bih...@compositence.de<mailto:benjamin.bih...@compositence.de>> wrote:
> Thank you for the suggestion.
>
> I have tried the following code snippets when the program starts up to set 
> the floating-point precision:
>
> ---
> unsigned int fpu_cw;
>  _controlfp_s(_cw, _PC_24, _MCW_PC);
> ---
> ...
> This does not help. Still the asynchronous thread gives different results. 
> Should I use different commands? Which ones?

I don't know anything about the details of _controlfp_s, etc., but I do have a 
debugging question.

Did any of your versions of calling _controlfp_s have any effect in that they 
changed the results produced by the main thread (even if those changed results 
did not match the results of the asynchronous thread)?

Or did your main thread still give the same results as without the _controlfp_s 
call?

Obviously, until you can change the behavior of the main thread, you can't 
change it to match the asynchronous threads.

In any event, hopefully someone on this list could tell you what call to 
_controlfp_s you need to match the floating-point environment that is getting 
set up for the asynchronous thread.  (I certainly can't.)

> Actually limiting the fp precision on the main thread would be a solution for 
> me, though it feels like a dirty workaround.

Yeah, you shouldn't have to use the less-favorable precision.  But that's the 
nature of work-arounds ...

Logically, I do think the idea should work.  Sorry i can't give you any detail 
on how to make it work.

(Of course, the better approach is to figure out how to make the child threads 
behave -- i.e., use the extended precision, and otherwise use a floating-point 
environment consistent with that of the main thread.)


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics 
Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net<mailto:Mingw-w64-public@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net<mailto:Mingw-w64-public@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140__

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

I have tried it, it does not change anything.

-Ursprüngliche Nachricht-
Von: JonY [mailto:jo...@users.sourceforge.net] 
Gesendet: Mittwoch, 16. März 2016 12:57
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

On 3/15/2016 23:15, Benjamin Bihler wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset 
> thread floating point settings on new thread") from the master branch 
> of the mingw64 repository, compiled it and replaced the respective 
> files in the "include" and "lib" folder of the "x86_64-mingw32"
> folder of my mingww64 5.3.0 installation with the newly compiled 
> files.
> 
> Then I have compiled my sample file with this modified mingw64 
> installation. It had no effect, the two threads give different 
> results. I have checked that the executable depends only on the DLLs 
> Kernel32.dll and Msvcrt.dll.
> 
> When I add
> 
> _fpreset()
> 
> as the first command of the method that is run asynchronously, both 
> threads give the same result. But this has already been the case with 
> the unmodified mingw64 compiler (without overwriting the link binaries 
> with those from the new revision), I have checked that.
> 
> My sample is a C++ sample, since I am using the gnu++11 features.
> 
> It would be painful for me, if I had to add _fpreset() to all methods 
> that I want to run asynchronously, especially since they may be part 
> of other libraries.
> 
> Did I patch my mingw64 installation in a wrong way? Otherwise it seems 
> as if the commit mentioned above does not solve my problem.
> 
> Does anyone have another idea? Thanks!


Hi,

Can you try with the latest code? I have just moved the _fpreset call, 
hopefully it gets called correctly this time.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Kai Tietz]

Hi Benjamin,

I would assume that there might be something wrong with your update of
crt.  What doesn't get clear to me by your description is what you build
and what you replaced actually.
The code in question is part of the crt build .a files. have you just
replace object code (as it sounds) or have you build an replaced complete
runtime?

Kai
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[K. Frank]

Hi Benjamin!

I have no idea how to patch mingw-w64 to do you you really want,
but perhaps I have a suggestion for a work-around, below.

On Tue, Mar 15, 2016 at 11:15 AM, Benjamin Bihler
 wrote:
> I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset thread 
> floating point settings on new thread") from the master branch of the mingw64 
> repository, compiled it and replaced the respective files in the "include" 
> and "lib" folder of the "x86_64-mingw32" folder of my mingww64 5.3.0 
> installation with the newly compiled files.
>
> Then I have compiled my sample file with this modified mingw64 installation. 
> It had no effect, the two threads give different results. I have checked that 
> the executable depends only on the DLLs Kernel32.dll and Msvcrt.dll.
>
> When I add
>
> _fpreset()
>
> as the first command of the method that is run asynchronously, both threads 
> give the same result. But this has already been the case with the unmodified 
> mingw64 compiler (without overwriting the link binaries with those from the 
> new revision), I have checked that.
>
> My sample is a C++ sample, since I am using the gnu++11 features.
>
> It would be painful for me, if I had to add _fpreset() to all methods that I 
> want to run asynchronously, especially since they may be part of other 
> libraries.
>
> Did I patch my mingw64 installation in a wrong way? Otherwise it seems as if 
> the commit mentioned above does not solve my problem.
>
> Does anyone have another idea? Thanks!

Disclaimer: I don't know anything about the patch or the _fpreset()
call.  Also, I am speaking from memory, so I may have some of
the details backwards.

Is it essential that you get the better, 80-bit long-double behavior,
or can you live with 64-bit long doubles as long as all threads
behave the same way?

As I understand it, the main thread starts with the 80-bit setting,
but somebody (mingw?, microsoft?) sets 64-bit behavior on
start-up of subsequent threads.

Perhaps you could -- just once, in your main thread -- set the
64-bit behavior when your program starts up.  Then (hopefully)
all new threads that automatically get 64-bit behavior will match
your main thread.

You would still have to call some sort of "_fpset(...)" once in
your main thread, but you would no longer have to add _fpreset
to all of your asynchronous methods.

(You might have to do some reverse engineering or ask on this
list to find out exactly what floating-point mode you need to set
for your main thread in order that it match that of the child treads.)

Sorry if this is all nonsense, but maybe it could help.


Good luck.


K. Frank

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

I have taken commit d82c6defa723b6e7986091ce0fb74da544b9e0f6 ("Reset thread 
floating point settings on new thread") from the master branch of the mingw64 
repository, compiled it and replaced the respective files in the "include" and 
"lib" folder of the "x86_64-mingw32" folder of my mingww64 5.3.0 installation 
with the newly compiled files.

Then I have compiled my sample file with this modified mingw64 installation. It 
had no effect, the two threads give different results. I have checked that the 
executable depends only on the DLLs Kernel32.dll and Msvcrt.dll.

When I add

_fpreset()

as the first command of the method that is run asynchronously, both threads 
give the same result. But this has already been the case with the unmodified 
mingw64 compiler (without overwriting the link binaries with those from the new 
revision), I have checked that.

My sample is a C++ sample, since I am using the gnu++11 features.

It would be painful for me, if I had to add _fpreset() to all methods that I 
want to run asynchronously, especially since they may be part of other 
libraries.

Did I patch my mingw64 installation in a wrong way? Otherwise it seems as if 
the commit mentioned above does not solve my problem.

Does anyone have another idea? Thanks!

-Ursprüngliche Nachricht-
Von: JonY [mailto:jo...@users.sourceforge.net] 
Gesendet: Montag, 7. März 2016 11:40
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

On 3/7/2016 17:32, Benjamin Bihler wrote:
> Thank you, Ruben and the others, for your answers.
> 
> I have tried myself to find a workaround, but haven’t been successful.
> 
> First I tried to add the O1 optimization flags one by one without 
> using –O1 to find out whether a special optimization flag influences 
> this behavior. I have learned that this is not the case, the “bug” 
> didn’t appear without –O1. That means that –O1 is more than the sum of 
> the optimizations activated by it. ;-)
> 
> Then I tried setting calling
> _controlfp_s(_cw, _PC_53, _MCW_PC); inside the getResult method 
> (i.e. in every thread?) to define the floating-point precision for 
> every thread. This also has failed. (I should stop trying to set 
> floating-point precisions manually, since I am not familiar with such 
> things.)
> 
> So I have no workaround right now.
> 
> Please let me explain why I am of the opinion that consistent results 
> are absolutely essential: I am using MinGW-w64 for CAD-related 
> software development (OpenCASCADE). Non-deterministic results make my 
> unit tests fail. But what is worse: if discrete values are computed 
> from the results of floating-point operations, the small 1.0e-16 
> difference may lead to a really big difference in the discrete values 
> (as different as “true” is from “false” or “0” is from “1”; if for 
> example it is detected whether a point is on a line by checking 
> whether the point has a distance smaller than 1.0e-7, and the point 
> actually has a distance of 1.0e-7, then one thread may say that it is 
> on the line and the other thread may say that it is not on the line). 
> This has already happened here. And things become even worse: I am 
> creating binary document files that store the input of my 
> computations, not the output. When I create such a document, close the 
> application, and open the document the
 next time, I cannot be sure that the content is still the same. Maybe another 
thread is doing the computation this time, which means that perhaps the content 
is different. If the data becomes inconsistent in itself (one point on a line 
is expected, but none is found anymore), I cannot even open the document 
without getting exceptions. This also has already happened here. ☹
> 
> As a conclusion, I would really appreciate if you continued to 
> consider my report. Thank you! ☺
> 

Try grabbing v4.x or master from git, tls code now calls fpreset for every new 
thread created.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Carl Kleffner]

Just to be sure:

_fpreset() maps to either

  __asm__ ("fninit")   // FPU  extended precision

 or

  (* __MINGW_IMP_SYMBOL(_fpreset))()  // FPU double precision

Is this correct? depending on wether CRT_fp10.o is linked in (default for
upstream mingw-w64) or CRT_fp8.o. My best guess is, that using mingw-w64 in
conjunction with OpenCASCADE should link CRT_fp8.o *if* OpenCASCADE was
compiled with MSVC.

Carl




2016-03-07 11:39 GMT+01:00 JonY :

> On 3/7/2016 17:32, Benjamin Bihler wrote:
> > Thank you, Ruben and the others, for your answers.
> >
> > I have tried myself to find a workaround, but haven’t been successful.
> >
> > First I tried to add the O1 optimization flags one by one without using
> –O1 to find out whether a special optimization flag influences this
> behavior. I have learned that this is not the case, the “bug” didn’t appear
> without –O1. That means that –O1 is more than the sum of the optimizations
> activated by it. ;-)
> >
> > Then I tried setting calling
> > _controlfp_s(_cw, _PC_53, _MCW_PC);
> > inside the getResult method (i.e. in every thread?) to define the
> floating-point precision for every thread. This also has failed. (I should
> stop trying to set floating-point precisions manually, since I am not
> familiar with such things.)
> >
> > So I have no workaround right now.
> >
> > Please let me explain why I am of the opinion that consistent results
> are absolutely essential: I am using MinGW-w64 for CAD-related software
> development (OpenCASCADE). Non-deterministic results make my unit tests
> fail. But what is worse: if discrete values are computed from the results
> of floating-point operations, the small 1.0e-16 difference may lead to a
> really big difference in the discrete values (as different as “true” is
> from “false” or “0” is from “1”; if for example it is detected whether a
> point is on a line by checking whether the point has a distance smaller
> than 1.0e-7, and the point actually has a distance of 1.0e-7, then one
> thread may say that it is on the line and the other thread may say that it
> is not on the line). This has already happened here. And things become even
> worse: I am creating binary document files that store the input of my
> computations, not the output. When I create such a document, close the
> application, and open the document the
>  next time, I cannot be sure that the content is still the same. Maybe
> another thread is doing the computation this time, which means that perhaps
> the content is different. If the data becomes inconsistent in itself (one
> point on a line is expected, but none is found anymore), I cannot even open
> the document without getting exceptions. This also has already happened
> here. ☹
> >
> > As a conclusion, I would really appreciate if you continued to consider
> my report. Thank you! ☺
> >
>
> Try grabbing v4.x or master from git, tls code now calls fpreset for
> every new thread created.
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[JonY]

On 3/7/2016 17:32, Benjamin Bihler wrote:
> Thank you, Ruben and the others, for your answers.
> 
> I have tried myself to find a workaround, but haven’t been successful.
> 
> First I tried to add the O1 optimization flags one by one without using –O1 
> to find out whether a special optimization flag influences this behavior. I 
> have learned that this is not the case, the “bug” didn’t appear without –O1. 
> That means that –O1 is more than the sum of the optimizations activated by 
> it. ;-)
> 
> Then I tried setting calling
> _controlfp_s(_cw, _PC_53, _MCW_PC);
> inside the getResult method (i.e. in every thread?) to define the 
> floating-point precision for every thread. This also has failed. (I should 
> stop trying to set floating-point precisions manually, since I am not 
> familiar with such things.)
> 
> So I have no workaround right now.
> 
> Please let me explain why I am of the opinion that consistent results are 
> absolutely essential: I am using MinGW-w64 for CAD-related software 
> development (OpenCASCADE). Non-deterministic results make my unit tests fail. 
> But what is worse: if discrete values are computed from the results of 
> floating-point operations, the small 1.0e-16 difference may lead to a really 
> big difference in the discrete values (as different as “true” is from “false” 
> or “0” is from “1”; if for example it is detected whether a point is on a 
> line by checking whether the point has a distance smaller than 1.0e-7, and 
> the point actually has a distance of 1.0e-7, then one thread may say that it 
> is on the line and the other thread may say that it is not on the line). This 
> has already happened here. And things become even worse: I am creating binary 
> document files that store the input of my computations, not the output. When 
> I create such a document, close the application, and open the document the
 next time, I cannot be sure that the content is still the same. Maybe another 
thread is doing the computation this time, which means that perhaps the content 
is different. If the data becomes inconsistent in itself (one point on a line 
is expected, but none is found anymore), I cannot even open the document 
without getting exceptions. This also has already happened here. ☹
> 
> As a conclusion, I would really appreciate if you continued to consider my 
> report. Thank you! ☺
> 

Try grabbing v4.x or master from git, tls code now calls fpreset for
every new thread created.




0xD4EBC740.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

Thank you, Ruben and the others, for your answers.

I have tried myself to find a workaround, but haven’t been successful.

First I tried to add the O1 optimization flags one by one without using –O1 to 
find out whether a special optimization flag influences this behavior. I have 
learned that this is not the case, the “bug” didn’t appear without –O1. That 
means that –O1 is more than the sum of the optimizations activated by it. ;-)

Then I tried setting calling
_controlfp_s(_cw, _PC_53, _MCW_PC);
inside the getResult method (i.e. in every thread?) to define the 
floating-point precision for every thread. This also has failed. (I should stop 
trying to set floating-point precisions manually, since I am not familiar with 
such things.)

So I have no workaround right now.

Please let me explain why I am of the opinion that consistent results are 
absolutely essential: I am using MinGW-w64 for CAD-related software development 
(OpenCASCADE). Non-deterministic results make my unit tests fail. But what is 
worse: if discrete values are computed from the results of floating-point 
operations, the small 1.0e-16 difference may lead to a really big difference in 
the discrete values (as different as “true” is from “false” or “0” is from “1”; 
if for example it is detected whether a point is on a line by checking whether 
the point has a distance smaller than 1.0e-7, and the point actually has a 
distance of 1.0e-7, then one thread may say that it is on the line and the 
other thread may say that it is not on the line). This has already happened 
here. And things become even worse: I am creating binary document files that 
store the input of my computations, not the output. When I create such a 
document, close the application, and open the document the next time, I cannot 
be sure that the content is still the same. Maybe another thread is doing the 
computation this time, which means that perhaps the content is different. If 
the data becomes inconsistent in itself (one point on a line is expected, but 
none is found anymore), I cannot even open the document without getting 
exceptions. This also has already happened here. ☹

As a conclusion, I would really appreciate if you continued to consider my 
report. Thank you! ☺

Von: Ruben Van Boxem [mailto:vanboxem.ru...@gmail.com]
Gesendet: Dienstag, 1. März 2016 17:18
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

2016-03-01 16:58 GMT+01:00 Daniel Franzini 
<daniel.franz...@gmail.com<mailto:daniel.franz...@gmail.com>>:
I think that comparing floating point numbers this way is wrong (well, at least 
in C it is) because you can't never know how is the precision of this 
comparison. It might be the case that in C++ the == operator is overloaded and 
it performs correctly using some pre-defined precision constant. I'm note sure 
about that.

if (b == c)
continue;

That is true in general, but here, it is used to compare the output of 
identical code.
The fact that this produces different outcomes on different threads has to do 
with Windows' floating point settings on thread creation and the way MinGW-w64 
handles it (C++ threads are handled through pthread):
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAGGsPMz%3D5w-2X_7bGSgWjEzyQFuwtBVCR%2BOm%3Dr-OA_zp8E2KdQ%40mail.gmail.com/#msg3303
more precisely:
https://sourceforge.net/p/mingw-w64/mailman/message/33080317/
I don't remember what the wanted behaviour is. I do know this is probably the 
cause for your inconsistency.
Ruben

On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler 
<benjamin.bih...@compositence.de<mailto:benjamin.bih...@compositence.de>> wrote:
Hello,

I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much: the 
results of floating-point operations may differ, if they are run on different 
threads. This does not happen with Visual Studio 2015 and not with g++ 4.9.2 on 
my Debian Linux.

Please consider the following program:

-
#include 
#include 
#include 
#include 
#include 

std::string getResult()
{
std::cout << "Thread id: " << std::this_thread::get_id() << std::endl;
std::string result = "Result:\n";

double a, b, c;
int i;
for (i = 0, a = 1.0; i < 1000; i++)
{
a *= 1.0001;
b = sqrt(a);
c = pow(a, 0.5);
if (b == c)
continue;
result += std::string("a: ") + std::to_string(a) + " b: "
+ std::to_string(b) + " c: " + 
std::to_string(c) + "\n";
}

return result;
}

int main()
{
std::string string1 = getResult();

std::future result = std::async(std:

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[K. Frank]

Hello Daniel!

Let me make a side comment not related to the core threading issue.

On Tue, Mar 1, 2016 at 10:58 AM, Daniel Franzini
 wrote:
> I think that comparing floating point numbers this way is wrong (well, at
> least in C it is) because you can't never know how is the precision of this
> comparison. It might be the case that in C++ the == operator is overloaded
> and it performs correctly using some pre-defined precision constant. I'm
> note sure about that.
>
> if (b == c)
> continue;

In practice, this kind of floating-point comparison is perfectly reasonably
(if you know what you're doing).

However, as far as I can tell, the standard is not inconsistent with what
you say.  The standard -- unless I've overlooked something -- is mightily
silent about floating-point comparisons, and floating-point arithmetic in
general.

The problem (of course) is that computer integers are not math integers
(computer integers have a finite range), nor are computer floating-point
numbers math real numbers (floating-point numbers have both a finite
range and precision, as well as potentially some special singular values).

The standard (I happen to be looking at the N3485 draft.) does say, for
example (5.7/3):

   The result of the binary + operator is the sum of the operands.
   The result of the binary - operator is the difference resulting from
   the subtraction of the second operand from the first.

We know what "sum" and "subtraction" mean for math numbers, but not
necessarily for computer numbers.

The standard helpfully adds that (3.9.1/4):

   Unsigned integers, declared unsigned, shall obey the laws of
   arithmetic modulo 2^n where n is the number of bits in the value
   representation of that particular size of integer.

This clears things up for unsigned (computer) integers, but not
for signed integers nor floating-point numbers.

The standard is equally silent about relational operators (<, ==, etc.).
Now, in practice, it is "implicit" in the standard or "understood" that
for computer integers the relational operators are defined the same
as they are for math integers.  It is also "understood" that the relational
operators are defined sensibly for floating-point numbers, but the
standard doesn't say this any where (as far as I know).

I don't think you can use the language that "the == operator is
overloaded" for floating-point numbers because I believe the standard
forbids overloading operators for fundamental types.  But I don't see
that the standard prohibits an implementation from defining (rather than
"overloading") floating-point == in terms of some "precision constant"
(epsilon tolerance).

Now, having gotten the lack of any standard legalese out of the way,
in practice, floating-point arithmetic is sensibly defined and deterministic.
You can be sure that 2.0 + 2.0 = 4.0, and that 2.1 + 2.1 is pretty darn
close to 4.2.  And code that relies on the fact that 2.1 + 2.1 != 177.9
is -- the standard notwithstanding -- well-formed, well-defined, and
portable.  Exactly how floating-point arithmetic works is (as it should
be) implementation dependent.  Some implementations comply with
the IEEE 754 floating-point standard (which itself gives some latitude
for differing implementations).

There are some weird things in many implementations (including IEEE
754). for example:

   0.0 == -0.0  (two different bit patterns test equal)
   NaN != NaN  (the same bit pattern tests unequal)

But the bottom line is you really are allowed to perform equality tests
on floating-point numbers (if you know what you are doing).  The test
is done exactly -- no approximate equality (done by hand, if you want
that) -- and exact tests are fully legitimate and are appropriate in some
cases (including Benjamin's, if I understand what he's about here).

For example:

   2.1 == 2.1
   2.1 + 2.1 == 2.1 + 2.1
   21.0 + 21.0 == 42.0

but the following might not hold:

   2.1 + 2.1 == 4.2
   3.0 * (1.0 / 3.0) == 1.0

And lastly (relevant to Benjamin's original post):

   2.1 + 2.1 (calculated in the main thread) == 2.1 + 2.1 (in a spawned thread)

really should hold.

(Benjamin's "if (b == c)" is meaningful and perfectly reasonable, and it's okay
if it sometimes fails.  He's asking whether sqrt(a) and pow(a, 0.5) are exactly
the same.  The standard is fully silent on this.  I believe that IEEE 754
gives latitude for these to differ.  When I run this with -O0, the test never
fails, but with -O1 I see differences at the level of 10^-16.  This is
not ideal,
but it is permitted and reasonable.  Benjamin's complaint is not that the test
fails, but that it fails differently depending upon which thread the calculation
is run in.  I agree with Benjamin that this shouldn't happen (unless done on
purpose) and I believe that Ruben's explanation that the "floating-point
environment" is set differently for different threads is correct.  This seems
wrong to me, but I have a vague 

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Kai Tietz]

Hi,

I think we can fix this issue by following approach.  I think a valid
fix would be the following. We might want to add a call to _fpreset()
in __dyn_tls_init() before the last for-loop (see  tlssup.c in
mingw-w64-crt/crt/

Kai

2016-03-02 16:51 GMT+01:00 Alberto Luaces :
> "Burkhardt, Glenn" writes:
>
>> You're probably running into the fact that Intel processors have
>> floating point registers with 80 bits, and when optimization is turned
>> on, operations are done in registers and not truncated as they are
>> when the values are stored to memory.
>>
>> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  Notice the number of 
>> duplicated reports - it's a surprise to a lot of people.
>>
>> There are ways to set the precision used by the FPU, e.g.,
>>
>> #include "fpu_control.h"
>>
>> fpu_control_t cw;
>> _FPU_GETCW(cw);
>> cw &= ~_FPU_EXTENDED;
>> cw |= _FPU_DOUBLE;
>> _FPU_SETCW(cw);
>
> Aren't those settings only useful int 32-bit code?[1]  It could matter
> depending if the OP's code is compiled in 64 or 32 bits.
>
>
> Footnotes:
> [1]  
> https://stackoverflow.com/questions/22710272/difference-in-floating-point-arithmetics-between-x86-and-x64
>
> --
> Alberto
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Alberto Luaces]

"Burkhardt, Glenn" writes:

> You're probably running into the fact that Intel processors have
> floating point registers with 80 bits, and when optimization is turned
> on, operations are done in registers and not truncated as they are
> when the values are stored to memory.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  Notice the number of 
> duplicated reports - it's a surprise to a lot of people.
>
> There are ways to set the precision used by the FPU, e.g.,
>
> #include "fpu_control.h"
>
> fpu_control_t cw;
> _FPU_GETCW(cw);
> cw &= ~_FPU_EXTENDED;
> cw |= _FPU_DOUBLE;
> _FPU_SETCW(cw);

Aren't those settings only useful int 32-bit code?[1]  It could matter
depending if the OP's code is compiled in 64 or 32 bits.


Footnotes: 
[1]  
https://stackoverflow.com/questions/22710272/difference-in-floating-point-arithmetics-between-x86-and-x64

-- 
Alberto


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

I have filed a bug report now. I guess that this is a non-legal behavior of 
MinGW.


-Ursprüngliche Nachricht-
Von: Benjamin Bihler [mailto:benjamin.bih...@compositence.de] 
Gesendet: Mittwoch, 2. März 2016 10:05
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

I have found some alternative code to set the floating-point precision:

 unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_53, _MCW_PC);

Instead of _PC_53 I have also tried _PC_24 and _PC_64. But this didn't help. 
The two threads still behave differently.

-Ursprüngliche Nachricht-
Von: Burkhardt, Glenn B UTAS [mailto:glenn.burkha...@utas.utc.com]
Gesendet: Dienstag, 1. März 2016 17:42
An: mingw-w64-public@lists.sourceforge.net
Betreff: [Mingw-w64-public] Floating-Point Operations Not Deterministic When 
Excecuted Asynchronously

You're probably running into the fact that Intel processors have floating point 
registers with 80 bits, and when optimization is turned on, operations are done 
in registers and not truncated as they are when the values are stored to memory.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  Notice the number of 
duplicated reports - it's a surprise to a lot of people.

There are ways to set the precision used by the FPU, e.g.,

#include "fpu_control.h"

fpu_control_t cw;
_FPU_GETCW(cw);
cw &= ~_FPU_EXTENDED;
cw |= _FPU_DOUBLE;
_FPU_SETCW(cw);


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + 
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end 
web transactions and take corrective actions now Troubleshoot faster and 
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + 
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end 
web transactions and take corrective actions now Troubleshoot faster and 
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

I have found some alternative code to set the floating-point precision:

 unsigned int fpu_cw;
 _controlfp_s(_cw, _PC_53, _MCW_PC);

Instead of _PC_53 I have also tried _PC_24 and _PC_64. But this didn't help. 
The two threads still behave differently.

-Ursprüngliche Nachricht-
Von: Burkhardt, Glenn B UTAS [mailto:glenn.burkha...@utas.utc.com] 
Gesendet: Dienstag, 1. März 2016 17:42
An: mingw-w64-public@lists.sourceforge.net
Betreff: [Mingw-w64-public] Floating-Point Operations Not Deterministic When 
Excecuted Asynchronously

You're probably running into the fact that Intel processors have floating point 
registers with 80 bits, and when optimization is turned on, operations are done 
in registers and not truncated as they are when the values are stored to memory.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  Notice the number of 
duplicated reports - it's a surprise to a lot of people.

There are ways to set the precision used by the FPU, e.g.,

#include "fpu_control.h"

fpu_control_t cw;
_FPU_GETCW(cw);
cw &= ~_FPU_EXTENDED;
cw |= _FPU_DOUBLE;
_FPU_SETCW(cw);


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + 
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end 
web transactions and take corrective actions now Troubleshoot faster and 
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

Thanks for your answer. This was also my suspect. But according to 
https://gcc.gnu.org/wiki/FloatingPointMath I had thought that -mfpmath=sse 
-msse2 should ensure that all operations are performed in SSE registers and 
therefore there should be no excessive precision problem. Do you know why these 
compile options seem not to work? Is the gcc wiki outdated? Are there newer 
documentations about floating point mathematics? Or do you know other compile 
flags that influence the floating point precision?

Your code seems really low level. Are you sure that this is necessary even when 
using SSE registers? Can you tell me where I can get fpu_control.h for 
MinGW-W64?

I will read the cited bug report carefully...

-Ursprüngliche Nachricht-
Von: Burkhardt, Glenn B UTAS [mailto:glenn.burkha...@utas.utc.com] 
Gesendet: Dienstag, 1. März 2016 17:42
An: mingw-w64-public@lists.sourceforge.net
Betreff: [Mingw-w64-public] Floating-Point Operations Not Deterministic When 
Excecuted Asynchronously

You're probably running into the fact that Intel processors have floating point 
registers with 80 bits, and when optimization is turned on, operations are done 
in registers and not truncated as they are when the values are stored to memory.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  Notice the number of 
duplicated reports - it's a surprise to a lot of people.

There are ways to set the precision used by the FPU, e.g.,

#include "fpu_control.h"

fpu_control_t cw;
_FPU_GETCW(cw);
cw &= ~_FPU_EXTENDED;
cw |= _FPU_DOUBLE;
_FPU_SETCW(cw);


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + 
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end 
web transactions and take corrective actions now Troubleshoot faster and 
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Óscar Fuentes]

Óscar Fuentes  writes:

> Daniel Franzini
>  writes:
>
>> I got it. The problem is that identical code is resulting different in two
>> different threads and not the fact that the code seems theoretically wrong.
>
> It is worse: spawning a thread affects the results of FP operations on
> the main thread. Please note that the example compares the results of
> two consecutive runs on the main thread.

Sorry, I misread the example code. It is comparing the result of the
main thread with the result of the new thread. Anyways, this is still
valid:

> This looks bad indeed.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Óscar Fuentes]

Daniel Franzini
 writes:

> I got it. The problem is that identical code is resulting different in two
> different threads and not the fact that the code seems theoretically wrong.

It is worse: spawning a thread affects the results of FP operations on
the main thread. Please note that the example compares the results of
two consecutive runs on the main thread.

This looks bad indeed.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Daniel Franzini]

I got it. The problem is that identical code is resulting different in two
different threads and not the fact that the code seems theoretically wrong.

Thanks for that.

On Tue, Mar 1, 2016 at 1:18 PM, Ruben Van Boxem 
wrote:

> 2016-03-01 16:58 GMT+01:00 Daniel Franzini :
>
>> I think that comparing floating point numbers this way is wrong (well, at
>> least in C it is) because you can't never know how is the precision of this
>> comparison. It might be the case that in C++ the == operator is overloaded
>> and it performs correctly using some pre-defined precision constant. I'm
>> note sure about that.
>>
>> if (b == c)
>> continue;
>>
>
> That is true in general, but here, it is used to compare the output of
> identical code.
>
> The fact that this produces different outcomes on different threads has to
> do with Windows' floating point settings on thread creation and the way
> MinGW-w64 handles it (C++ threads are handled through pthread):
>
> https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAGGsPMz%3D5w-2X_7bGSgWjEzyQFuwtBVCR%2BOm%3Dr-OA_zp8E2KdQ%40mail.gmail.com/#msg3303
> more precisely:
> https://sourceforge.net/p/mingw-w64/mailman/message/33080317/
>
> I don't remember what the wanted behaviour is. I do know this is probably
> the cause for your inconsistency.
>
> Ruben
>
>
>> On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
>> benjamin.bih...@compositence.de> wrote:
>>
>>> Hello,
>>>
>>> I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much:
>>> the results of floating-point operations may differ, if they are run on
>>> different threads. This does not happen with Visual Studio 2015 and not
>>> with g++ 4.9.2 on my Debian Linux.
>>>
>>> Please consider the following program:
>>>
>>> -
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> std::string getResult()
>>> {
>>> std::cout << "Thread id: " << std::this_thread::get_id() <<
>>> std::endl;
>>> std::string result = "Result:\n";
>>>
>>> double a, b, c;
>>> int i;
>>> for (i = 0, a = 1.0; i < 1000; i++)
>>> {
>>> a *= 1.0001;
>>> b = sqrt(a);
>>> c = pow(a, 0.5);
>>> if (b == c)
>>> continue;
>>> result += std::string("a: ") + std::to_string(a) + " b: "
>>> + std::to_string(b) + " c: " +
>>> std::to_string(c) + "\n";
>>> }
>>>
>>> return result;
>>> }
>>>
>>> int main()
>>> {
>>> std::string string1 = getResult();
>>>
>>> std::future result = std::async(std::launch::async,
>>> getResult);
>>>
>>> std::string string2 = result.get();
>>>
>>> if (string1 != string2)
>>> {
>>> std::cout << "String 1 is: " << std::endl << string1 <<
>>> std::endl
>>> << " and string 2 is: " << std::endl <<
>>> string2 << std::endl;
>>> }
>>> else
>>> {
>>> std::cout << "The results are the same." << std::endl;
>>> }
>>>
>>> return 0;
>>> }
>>> -
>>>
>>> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>>>
>>> -
>>> Thread id: 1
>>> Thread id: 2
>>> The results are the same.
>>> -
>>>
>>> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
>>> -
>>> Thread id: 1
>>> Thread id: 2
>>> String 1 is: ...
>>> -
>>>
>>> The same happens with "-O2".
>>>
>>> If I change the line
>>> std::future result = std::async(std::launch::async,
>>> getResult);
>>> to
>>> std::future result = std::async(getResult);
>>> then the result is independent from the optimization flag the following:
>>>
>>> -
>>> Thread id: 1
>>> Thread id: 1
>>> The results are the same.
>>> -
>>>
>>> What actually disturbs me, is that the results differ with asynchronous
>>> execution and optimization turned on. I tried parameters like -ffloat-store
>>> -msse2 -mfpmath=sse to have consistent floating-point operation results,
>>> but this won't help.
>>>
>>> Is this a bug? Or are there compiler flags that force the floating-point
>>> operation results to be consistent?
>>>
>>> Any help is greatly appreciated!
>>>
>>> Regards,
>>> Benjamin
>>>
>>>
>>> --
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor 

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Ruben Van Boxem]

2016-03-01 16:58 GMT+01:00 Daniel Franzini :

> I think that comparing floating point numbers this way is wrong (well, at
> least in C it is) because you can't never know how is the precision of this
> comparison. It might be the case that in C++ the == operator is overloaded
> and it performs correctly using some pre-defined precision constant. I'm
> note sure about that.
>
> if (b == c)
> continue;
>

That is true in general, but here, it is used to compare the output of
identical code.

The fact that this produces different outcomes on different threads has to
do with Windows' floating point settings on thread creation and the way
MinGW-w64 handles it (C++ threads are handled through pthread):
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAGGsPMz%3D5w-2X_7bGSgWjEzyQFuwtBVCR%2BOm%3Dr-OA_zp8E2KdQ%40mail.gmail.com/#msg3303
more precisely:
https://sourceforge.net/p/mingw-w64/mailman/message/33080317/

I don't remember what the wanted behaviour is. I do know this is probably
the cause for your inconsistency.

Ruben


> On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
> benjamin.bih...@compositence.de> wrote:
>
>> Hello,
>>
>> I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much:
>> the results of floating-point operations may differ, if they are run on
>> different threads. This does not happen with Visual Studio 2015 and not
>> with g++ 4.9.2 on my Debian Linux.
>>
>> Please consider the following program:
>>
>> -
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> std::string getResult()
>> {
>> std::cout << "Thread id: " << std::this_thread::get_id() <<
>> std::endl;
>> std::string result = "Result:\n";
>>
>> double a, b, c;
>> int i;
>> for (i = 0, a = 1.0; i < 1000; i++)
>> {
>> a *= 1.0001;
>> b = sqrt(a);
>> c = pow(a, 0.5);
>> if (b == c)
>> continue;
>> result += std::string("a: ") + std::to_string(a) + " b: "
>> + std::to_string(b) + " c: " +
>> std::to_string(c) + "\n";
>> }
>>
>> return result;
>> }
>>
>> int main()
>> {
>> std::string string1 = getResult();
>>
>> std::future result = std::async(std::launch::async,
>> getResult);
>>
>> std::string string2 = result.get();
>>
>> if (string1 != string2)
>> {
>> std::cout << "String 1 is: " << std::endl << string1 <<
>> std::endl
>> << " and string 2 is: " << std::endl <<
>> string2 << std::endl;
>> }
>> else
>> {
>> std::cout << "The results are the same." << std::endl;
>> }
>>
>> return 0;
>> }
>> -
>>
>> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>>
>> -
>> Thread id: 1
>> Thread id: 2
>> The results are the same.
>> -
>>
>> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
>> -
>> Thread id: 1
>> Thread id: 2
>> String 1 is: ...
>> -
>>
>> The same happens with "-O2".
>>
>> If I change the line
>> std::future result = std::async(std::launch::async,
>> getResult);
>> to
>> std::future result = std::async(getResult);
>> then the result is independent from the optimization flag the following:
>>
>> -
>> Thread id: 1
>> Thread id: 1
>> The results are the same.
>> -
>>
>> What actually disturbs me, is that the results differ with asynchronous
>> execution and optimization turned on. I tried parameters like -ffloat-store
>> -msse2 -mfpmath=sse to have consistent floating-point operation results,
>> but this won't help.
>>
>> Is this a bug? Or are there compiler flags that force the floating-point
>> operation results to be consistent?
>>
>> Any help is greatly appreciated!
>>
>> Regards,
>> Benjamin
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
>
> --
> Daniel
>
> "Let us 

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Benjamin Bihler]

Thank you for your answer, but I do not mind. What upsets me is that the method 
getResult behaves differently, if it runs in another thread! This shouldn’t be 
the case! Never, never, never ever! Or am I wrong?

Von: Daniel Franzini [mailto:daniel.franz...@gmail.com]
Gesendet: Dienstag, 1. März 2016 16:58
An: mingw-w64-public@lists.sourceforge.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic 
When Excecuted Asynchronously

I think that comparing floating point numbers this way is wrong (well, at least 
in C it is) because you can't never know how is the precision of this 
comparison. It might be the case that in C++ the == operator is overloaded and 
it performs correctly using some pre-defined precision constant. I'm note sure 
about that.

if (b == c)
continue;

On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler 
<benjamin.bih...@compositence.de<mailto:benjamin.bih...@compositence.de>> wrote:
Hello,

I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much: the 
results of floating-point operations may differ, if they are run on different 
threads. This does not happen with Visual Studio 2015 and not with g++ 4.9.2 on 
my Debian Linux.

Please consider the following program:

-
#include 
#include 
#include 
#include 
#include 

std::string getResult()
{
std::cout << "Thread id: " << std::this_thread::get_id() << std::endl;
std::string result = "Result:\n";

double a, b, c;
int i;
for (i = 0, a = 1.0; i < 1000; i++)
{
a *= 1.0001;
b = sqrt(a);
c = pow(a, 0.5);
if (b == c)
continue;
result += std::string("a: ") + std::to_string(a) + " b: "
+ std::to_string(b) + " c: " + 
std::to_string(c) + "\n";
}

return result;
}

int main()
{
std::string string1 = getResult();

std::future result = std::async(std::launch::async, 
getResult);

std::string string2 = result.get();

if (string1 != string2)
{
std::cout << "String 1 is: " << std::endl << string1 << 
std::endl
<< " and string 2 is: " << std::endl << string2 
<< std::endl;
}
else
{
std::cout << "The results are the same." << std::endl;
}

return 0;
}
-

If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is

-
Thread id: 1
Thread id: 2
The results are the same.
-

If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
-
Thread id: 1
Thread id: 2
String 1 is: ...
-

The same happens with "-O2".

If I change the line
std::future result = std::async(std::launch::async, 
getResult);
to
std::future result = std::async(getResult);
then the result is independent from the optimization flag the following:

-
Thread id: 1
Thread id: 1
The results are the same.
-

What actually disturbs me, is that the results differ with asynchronous 
execution and optimization turned on. I tried parameters like -ffloat-store 
-msse2 -mfpmath=sse to have consistent floating-point operation results, but 
this won't help.

Is this a bug? Or are there compiler flags that force the floating-point 
operation results to be consistent?

Any help is greatly appreciated!

Regards,
Benjamin

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net<mailto:Mingw-w64-public@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Daniel

"Let us change our traditional attitude to the construction of programs. 
Instead of imagining that our main task is to instruct a computer what to do, 
let us concentrate rather on explaining to human beings what we want a computer 
to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other.

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Daniel Franzini]

I think that comparing floating point numbers this way is wrong (well, at
least in C it is) because you can't never know how is the precision of this
comparison. It might be the case that in C++ the == operator is overloaded
and it performs correctly using some pre-defined precision constant. I'm
note sure about that.

if (b == c)
continue;

On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
benjamin.bih...@compositence.de> wrote:

> Hello,
>
> I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much:
> the results of floating-point operations may differ, if they are run on
> different threads. This does not happen with Visual Studio 2015 and not
> with g++ 4.9.2 on my Debian Linux.
>
> Please consider the following program:
>
> -
> #include 
> #include 
> #include 
> #include 
> #include 
>
> std::string getResult()
> {
> std::cout << "Thread id: " << std::this_thread::get_id() <<
> std::endl;
> std::string result = "Result:\n";
>
> double a, b, c;
> int i;
> for (i = 0, a = 1.0; i < 1000; i++)
> {
> a *= 1.0001;
> b = sqrt(a);
> c = pow(a, 0.5);
> if (b == c)
> continue;
> result += std::string("a: ") + std::to_string(a) + " b: "
> + std::to_string(b) + " c: " +
> std::to_string(c) + "\n";
> }
>
> return result;
> }
>
> int main()
> {
> std::string string1 = getResult();
>
> std::future result = std::async(std::launch::async,
> getResult);
>
> std::string string2 = result.get();
>
> if (string1 != string2)
> {
> std::cout << "String 1 is: " << std::endl << string1 <<
> std::endl
> << " and string 2 is: " << std::endl <<
> string2 << std::endl;
> }
> else
> {
> std::cout << "The results are the same." << std::endl;
> }
>
> return 0;
> }
> -
>
> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>
> -
> Thread id: 1
> Thread id: 2
> The results are the same.
> -
>
> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
> -
> Thread id: 1
> Thread id: 2
> String 1 is: ...
> -
>
> The same happens with "-O2".
>
> If I change the line
> std::future result = std::async(std::launch::async,
> getResult);
> to
> std::future result = std::async(getResult);
> then the result is independent from the optimization flag the following:
>
> -
> Thread id: 1
> Thread id: 1
> The results are the same.
> -
>
> What actually disturbs me, is that the results differ with asynchronous
> execution and optimization turned on. I tried parameters like -ffloat-store
> -msse2 -mfpmath=sse to have consistent floating-point operation results,
> but this won't help.
>
> Is this a bug? Or are there compiler flags that force the floating-point
> operation results to be consistent?
>
> Any help is greatly appreciated!
>
> Regards,
> Benjamin
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>



-- 
Daniel

"Let us change our traditional attitude to the construction of programs.
Instead of imagining that our main task is to instruct a computer what to
do, let us concentrate rather on explaining to human beings what we want a
computer to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other." (
http://www.boogieonline.com/revolution/science/humor/)"

"Man is driven to create; I know I really love to create things. And while
I'm not good at painting, drawing, or music, I can write software."
(Yukihiro Matsumoto, a.k.a. ``Matz'')
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user