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

[sisyphus1]

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