sisyphus1 wrote >>Now I am compiling GSL 2.4 (latest commit) using the newer >> Microsoft Runtime DLL, I hope to fix the failing test during "make check".
> If that fixes the problem, then I think that would pretty much prove that the bug is in the MS >runtime. >So please let me know how that goes. Yes. Fixed. Linking with msvcrt110 (Visual C++ 2012) instead of using msvcrt solves the issue. The full "make check" is successful now (using latest commit) If you test GSL using a newer ddl for linking the runtime (I used msvcrt110). Please note that the libmoldname110.a should be used (it should be manually created) as well. make check-TESTS make[2]: Entering directory '/home/test-admin/gsl-2.4/specfunc' make[3]: Entering directory '/home/test-admin/gsl-2.4/specfunc' PASS: test.exe make[4]: Entering directory '/home/test-admin/gsl-2.4/specfunc' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/test-admin/gsl-2.4/specfunc' ============================================================================ Testsuite summary for gsl 2.4 ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ make[3]: Leaving directory '/home/test-admin/gsl-2.4/specfunc' make[2]: Leaving directory '/home/test-admin/gsl-2.4/specfunc' make[1]: Leaving directory '/home/test-admin/gsl-2.4/specfunc' Making check in dht 2017-06-23 12:41 GMT+02:00 <[email protected]>: > > From: Max Gaspa > Sent: Friday, June 23, 2017 7:50 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [Help-gsl] test release for GSL 2.4 > > sisyphus1 wrote >> >>> >>> This would make it a bug in the mingw runtime, right ? >>> >> >> I wouldn't agree with you. The difference you are observing is related to >> the computation of sin(x) and cos(x) at compilte time (using MPFR) when >> optimization is used. Without optimization the sin(x) and cos(x) are >> computed at runtime using sin and cos from the runtime library provided by >> Microsoft (not MinGW64). MinGW is just providing import libraries for the >> Microsoft Runtime dll. >> >> Try to input, in your test case, the value of x using scanf, instead of >> assigning the value during declaration. You get wrong values regardless the >> used optimization flag, because now sin and cos are computed at runtime >> even using optimization. >> > > Yes, as I said in my last post: > > [quote] > The key to getting the correct result is in doing the calculations at > compile-time. If the calculations can't be done at compile-time, then you > get an incorrect result (irrespective of optimization level). > [end quote] > > So I think we're agreeing there. > > In my humble opinion the "bug" (I mean bad sin(x) and cos(x) values) >> >> 1) is not in GSL >> 2) is not in MinGW64 >> 3) is due to the older runtime library provided by Microsoft in the OS >> > > Your first point is certainly correct. > You could well be right about points 2) and 3) as well. It's not unusual > for me to be wrong. > > Now I am compiling GSL 2.4 (latest commit) using the newer Microsoft >> Runtime DLL, I hope to fix the failing test during "make check". >> > > If that fixes the problem, then I think that would pretty much prove that > the bug is in the MS runtime. > So please let me know how that goes. > > Cheers, > Rob > > >
