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

[Max Gaspa]

(Please note the nicknames MaxGaspa and maxgacode are the same person (me)
, I have to fix Google mail....)

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.

I tested you snippet code using the old  "standard" Microsoft Standard
Library mscvrt.dll (used by default by MinGW because it should be present
in all Windows distribution). And the bad values for sin(x) and cos(x) are
observed (I mean using NO optimization). Then I switched options to link
with the Visual C++ 2012 runtime library and the bug disappeared from your
testing code, correct values are obtained with and without optimization.

The lack of precision for sin(x) and cos(x) is known ad it depends on the
runtime library. Intel itself is suggesting to use their (in 2010) runtime
library to avoid cancellation errors during range reduction.


https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/289702

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

Please try to re-test your snippet code linking with  Visual C++ 2012
runtime library (just use the MinGW64 import library libmsvcr110.a ).

Using

gcc.exe -Wall -m64 -g -IC:\MinGW\x86_64-w64-mingw32\include
-IC:\Development\include -IC:\Development\Projects\test
-IC:\Development\Projects\test -c C:\Development\Projects\test\main.c -o
obj\Debug\main.o

g++.exe -LC:\MinGW\x86_64-w64-mingw32\include -LC:\Development\lib -o
bin\Debug\test.exe obj\Debug\main.o -m64 -lmsvcr110

I get

-3.1518539455252417e-007
Runtime: 5.0
sin: 3.3049314002173469e-001
cos: 9.4380839390131199e-001

Process returned 0 (0x0)   execution time : 0.020 s
Press any key to continue.
That is the "correct" result.


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".

Please note: The newer runtime library may not be present in your OS. You
may need to install the

Visual C++ Redistributable for Visual Studio 2012 Update 4

from Microsoft to get it.






2017-06-23 3:56 GMT+02:00 <address@hidden>:

> -----Original Message----- From: maxgacode
> Sent: Friday, June 23, 2017 5:43 AM
> To: address@hidden
> Subject: Re: [Help-gsl] test release for GSL 2.4
>
> Il 22/06/2017 04:30, address@hidden ha scritto:
>>
>>
>>> And the specfunc failure that we see is because gcc-6.3.0 gives us the
>>> wrong trig values.
>>> Switching to gcc-7.1.0 fixes this problem for me - as gcc-7.1.0 agrees
>>> with MPFR.
>>>
>>>
>> That is not true for me. Using GCC 7.1.0 (64 bit MinGW-w64 , SEH, Win
>> Thread, Windows 7 64 bit) I'm still observing the failure in specfun due to
>> Bessel test failure.
>>
>> I tested -mgloat-store , SSE2, -O2 (with and without).
>>
>> Which compilere are you using? Which compilation flag are you using for
>> compiling GSL?
>>
>
> I tested by running this script (and didn't build gsl-2.4 using gcc-7.1.0
> at all):
>
> /***********************/
>
> #include <stdio.h>
> #include <math.h>
>
> int main(void) {
>
> double ret, x = 1048576.0;
>
> ret = (
>       (((3 / (x * x)) - 1) * sin(x)) -
>       (3 * cos(x) / x)
>       ) / x;
>
> printf("%.16e\n", ret);
>
> printf("Runtime: %d.%d\n", __MINGW64_VERSION_MAJOR,
> __MINGW64_VERSION_MINOR);
>
> printf("sin: %.16e\ncos: %.16e\n", sin(x), cos(x));
>
> return 0;
> }
>
> /***********************/
>
> And I compiled the executable with:
>
> gcc -o j2.exe j2.c
>
> Using 6.3.0 (x86_64-posix-sjlj-rev1) that script outputs:
>
> -3.1518539455252539e-007
> Runtime: 5.0
> sin: 3.3049314002173596e-001
> cos: 9.4380839390131155e-001
>
> These are the incorrect values that the specfunc test sees.
>
> But then I've apparently made a mistake :-(
> I thought I then got correct values when I switched to using 7.1.0
> (x86_64-posix-seh-rev0) ... but I can't reproduce that this morning. (It's
> producing the same wrong output as 6.3.0.)
>
> However,  as soon as I add some optimization to the command line (eg 'gcc
> -o j2.exe j2.c -O1'), that program then starts giving correct results:
>
> ##########################
> C:\_32\C>gcc -o j2.exe j2.c -O1
>
> C:\_32\C>j2
> -3.1518539455252417e-007
> Runtime: 5.0
> sin: 3.3049314002173469e-001
> cos: 9.4380839390131199e-001
>
> ##########################
>
> Levels -O2 and -O3 also produce correct results.
> And this happens with both 6.3.0 and 7.1.0.
>
> So the error with that program occurs only when built without optimization.
>
> I think that with optimization turned on, the optimizer works out that it
> can do the calculations in that script at compile-time  ... which results
> in a correct outcome.
> But without optimization turned on, the calculations get done at run-time
> ... which results in an incorrect outcome.
> (I've run some other programs to check on this, and their output supports
> this view.)
>
> This would make it a bug in the mingw runtime, right ?
> I see the same behaviour in version 4 of the mingw runtime, so it has been
> around for a while - and I don't see any bug reports about it.
>
> 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).
>
> I've done some (very brief) checking to see what other inputs (apart from
> 1048576.0) are affected by this bug - and it seems that the bug doesn't
> kick in until the input value gets to around 60000.0.
> For 60000.0 the run-time result is incorrect, but for 50000.0 and below
> the run-time calculation is done correctly ... but I need to look more
> closely at this before I submit the bug report to
> https://sourceforge.net/p/mingw-w64/bugs .
>
> My apologies for yesterday's incompetence ... I hope it didn't waste too
> much of your time.
>
> Cheers,
> Rob
>
>
>
>