Re: [Help-gsl] test release for GSL 2.4

[Max Gaspa]

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 <address@hidden>:

>
> From: Max Gaspa
> Sent: Friday, June 23, 2017 7:50 PM
> To: address@hidden
> Cc: address@hidden
> 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
>
>
>