g, as this is unexpected and does
not fit the usual recommendation to link CRT-fp8.o for the case that
53 bit precision is wanted by the user. The only workaround in this setting is
to statically link winpthreads.
Carl
Am Do., 6. Mai 2021 um 16:33 Uhr schrieb Benjamin Bihler <
case of using static build libwinpthreads.a this patch
would not apply.
Am Do., 6. Mai 2021 um 15:55 Uhr schrieb Benjamin Bihler <
benjamin.bih...@compositence.de>:
> I have checked it, the patch 295fafc is included in v8 of mingw-w64
> when building the compiler with mingw-builds. B
C++ programs, but I'm not
sure.
Am Do., 6. Mai 2021 um 10:11 Uhr schrieb Benjamin Bihler <
benjamin.bih...@compositence.de>:
> It may have to do something with the commit you have mentioned. I am
> not sure... I am a compiler end user, not a compiler developer. What
>
not with C++ programs, but I'm not
sure.
Am Do., 6. Mai 2021 um 10:11 Uhr schrieb Benjamin Bihler <
benjamin.bih...@compositence.de>:
> It may have to do something with the commit you have mentioned. I am
> not sure... I am a compiler end user, not a compiler developer. What
>
It may have to do something with the commit you have mentioned. I am not
sure... I am a compiler end user, not a compiler developer. What does that
mean? That linking CRT_fp8 or CRT_fp10 is not the right way anymore to set x87
precision?
Benjamin
-Ursprüngliche Nachricht-
Von: Liu Hao
Precision
Changes With Gcc 10.3
I can't reproduce this behaviour. With gcc-10.3 on msys2/ucrt64 as well as
msy2/mingw64 I get consistent results, regardless if I link CRT_fp10.o,
CRT_fp8.o or none of them.
Cheers
Carl
Am Di., 4. Mai 2021 um 14:52 Uhr schrieb Benjamin Bihler <
benj
-floating-point-precision-depend-on-winpthreads-version.
Is this a bug? What can I do to have consistent precision again? Thank you
very much.
Best regards,
Benjamin Bihler
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https
Hi,
I am working with Open CASCADE, which also supports MinGW-w64. It is not
possible to open files with special characters in their names when Open CASCADE
has been compiled with MinGW-w64, because of its missing w_char support. Please
note that the Open CASCADE code needs to open ifstream and
64 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
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-w
[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
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
mailto:benjamin.bih
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 respect
64-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 O
his is probably the
cause for your inconsistency.
Ruben
On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler
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
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
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 didn't help.
The two threads still behave differently.
-Ursprüngliche Nachri
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 thes
s 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, Benja
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
20 matches
Mail list logo
