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 <jo...@users.sourceforge.net>:
> 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(&fpu_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
