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 progra
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 N
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
n
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 i
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 corr
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 compari
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
Ó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 t
@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 an
rü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 ru
] 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(&fpu_cw, _PC_53, _MCW_PC);
Instead of _PC_53 I have also tried _PC_24 and _PC_64. But this di
"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.gn
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" w
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
> co
.net
Betreff: Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic
When Excecuted Asynchronously
2016-03-01 16:58 GMT+01:00 Daniel Franzini
mailto:daniel.franz...@gmail.com>>:
I think that comparing floating point numbers this way is wrong (well, at least
in C it is) because
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 f
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 usin
ise 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-w
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 setting
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 h
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
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, Ben
: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 <
> benjam
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(&fpu_cw, _PC_24, _MCW_PC);
> ---
> ..
[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
wrote:
> Thank you for the suggestion.
>
&g
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
y 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-w
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
28 matches
Mail list logo