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 :

>
> From: Max Gaspa
> Sent: Friday, June 23, 2017 7:50 PM
> To: sisyph...@optusnet.com.au
> Cc: help-gsl@gnu.org
> 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
>
>
>

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

[sisyphus1]

From: Max Gaspa
Sent: Friday, June 23, 2017 7:50 PM
To: sisyph...@optusnet.com.au
Cc: help-gsl@gnu.org
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

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 :

> -Original Message- From: maxgacode
> Sent: Friday, June 23, 2017 5:43 AM
> To: help-gsl@gnu.org
> Subject: Re: [Help-gsl] test release for GSL 2.4
>
> Il 22/06/2017 04:30, sisyph...@optusnet.com.au 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 
> #include 
>
> 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

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

[sisyphus1]

-Original Message- 
From: maxgacode

Sent: Friday, June 23, 2017 5:43 AM
To: help-gsl@gnu.org
Subject: Re: [Help-gsl] test release for GSL 2.4


Il 22/06/2017 04:30, sisyph...@optusnet.com.au 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 
#include 

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 6.0.
For 6.0 the run-time result is incorrect, but for 5.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

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

[maxgacode]

Il 22/06/2017 10:45, Patrick Alken ha scritto:


It would be great if a windows person can test the latest git repository
to see if the issue is fixed



Yes. Using last commit in Git works and the issue seems fixed. Tested 
with both GCC 6.1.0 and 7.1.0. Windows 7.


Max

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

[maxgacode]

Il 22/06/2017 04:30, sisyph...@optusnet.com.au 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?


Max

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

[sisyphus1]

-Original Message- 
From: Patrick Alken

Sent: Thursday, June 22, 2017 6:45 PM
To: help-gsl@gnu.org
Subject: Re: [Help-gsl] test release for GSL 2.4

It would be great if a windows person can test the latest git repository 
to see if the issue is fixed.


Built and tested current git (commit 
d87d114206ca88e0e5aef2b7014b12906a345a75) and it went well for me.


Only failing test now is specfunc - but, as I mentioned elsewhere in this 
thread, that's a mingw bug.


Cheers,
Rob

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

[David Komanek]

Hi,

each process and thread has its unique id, is it possible to construct
the filename using these numbers ? Or, is UUID ANSI-compliant ?

Regards,

  David


On 06/22/2017 10:28 AM, Mohammad Akhlaghi wrote:
> Hi Patrick,
>
> Thanks for the correction. 
>
> So the two tests are identical except for the versions of the functions. 
> Can't they also differ in the filename they use? 
>
> For example one could read/write to "test-non-inline.dat" and the other to 
> "test-inline.dat".
>
> Cheers,
> Mohammad
>
> On June 22, 2017 9:00:22 AM GMT+01:00, Patrick Alken  
> wrote:
>> Its not a race condition between the files written by matrix/vector.
>> The
>> vector module itself has two test programs, which are identical except
>> one tests the non-inline versions of the functions and the other tests
>> the inline versions. So if these two tests are run in parallel, via
>> make
>> check -j8, they will write the same test file name at the same time if
>> we use a static filename.
>>
>> Patrick
>>
>> On 06/22/2017 09:56 AM, Mohammad Akhlaghi wrote:
>>> Hi Patrick,
>>>
>>> How about using two separate files (file names) for vector and matrix
>>> tests?
>>>
>>> For example "test-vector.dat" and "test-matrix.dat".
>>>
>>> Cheers,
>>> Mohammad
>>>
>>> On June 22, 2017 8:12:06 AM GMT+01:00, Patrick Alken
>>>  wrote:
>>>
>>> In GSL 2.3 and earlier, the vector and matrix modules tested the
>>> fwrite/fread routines by creating temporary files with mkstemp()
>> and
>>> fdopen(). Unfortunately neither of these routines conform to the
>> ANSI
>>> C89 standard and so I converted these tests to write to a fixed
>> filename
>>> "test.dat". However this caused the file race condition which was
>>> reported in the recent test candidates (i.e. the "make check -j8"
>>> error). So finally I switched to use tmpfile() which is C89 and
>> seems to
>>> be the only ANSI-compatible method of using temporary files in C.
>> But
>>> now it seems that some windows systems fail with this method due
>> to
>>> permission restrictions.
>>>
>>> I can certainly modify the tests to check for a NULL pointer
>> coming out
>>> of tmpfile, but this would then disable these tests on your
>> windows
>>> systems, which is not ideal either. It appears we must either
>> accept
>>> that the matrix/vector fread/fwrite routines cannot be properly
>> tested
>>> on windows systems, or go back to a non-ANSI method of writing
>> the
>>> temporary files. Neither of these choices seem good to me, but my
>>> preference would be to follow the C89 standard if possible.
>>>
>>> I thought about writing a routine inside GSL to perform the same
>> task as
>>> mkstemp() does, but it seems this is not possible in C89 since
>> mkstemp
>>> relies on calling open() with O_EXCL to raise an error if the
>> file
>>> already exists, but open() is also not C89.
>>>
>>> I am open to suggestions if anyone knows of a solution to this
>> problem.
>>> Patrick
>>>
>>> On 06/21/2017 03:26 PM, Max Gaspa wrote:
>>>
>>> Dear all, Sisyphus wrote
>>>
>>> Much the same situation here - Windows 7 64 bit,
>> mingw-w64
>>> port of 64-bit gcc-6.3.0 (x86_64-posix-sjlj-rev1). And,
>>> like you (apparently), I didn't test the release
>>> candidates :-( 
>>>
>>> Yes. And Yes. I didn't check the release candidate because
>> the
>>> short time between the availability of the RC and the
>>> availability of the official release. Anyway I think I found
>>> the reason of the issue just following the program flow with
>>> gdb. The issue is NOT related to malloc(0) (I' still thinking
>>> that is not a good programming practice but I will accept it
>>> :-) ) I'm discussing the issue for vector just to describe it
>>> in a simpler way. The reason of the segmentation fault is the
>>> latest modification made by Patrick 7 days ago into
>>> test_source.c ( described by "fix file race condition for
>>> 'make check -j8'" ). The lines involved are - char filename[]
>>> = "test.dat"; + FILE *f = tmpfile(); in few words the change
>>> imply using tmpfile(). Unfortunately in Windows (XP is fine!
>> 7
>>> fails) that call is creating a temporary file in C:\ that is
>>> usually not writable for security reason. The call fails and
>>> the pointer f is NULL. Because there are no checking for NULL
>>> after the call to tmpfile() (It seems GSL developer love not
>>> checking for null pointer :-) :-) :-) ) and the next call
>>> to fprintf will use NULL as its stream you get the
>>> segmentation fault. Now I'm trying to revert the change (just
>>> using the release candidate version should be fine) to see if
>>> the issue is fixed, but I'm quite sure because gdb told me
>>> that f was NULL but it 

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

[Patrick Alken]

I tried Mohammad's suggestion, and the tests now write two files in the
current working directory: "test.dat" and "test_static.dat". This
appears to be working correctly on my system with make check -j8. All
function calls to tmpfile() have been removed.

It would be great if a windows person can test the latest git repository
to see if the issue is fixed

Thanks,
Patrick

On 06/22/2017 10:41 AM, Brian Gladman wrote:
> I assume that by 'race condition' you mean that any tests running in
> parallel would both be using the same file (IIRC "test.dat").
>
> If so, you could possibly revert your change and use the tmpnam()
> function to set the filename to be used.
>
> I don't know where the resulting file would be placed with GCC but on
> Windows this will return a filename that is unique in the current
> working directory, which would be likely to have the right access
> permission.  However, the MS documentation simply says that
>
> "tmpnam returns a name unique in the current working directory"
>
> which suggests that this won't solve the race condition.
>
> We could possibly maintain full c89 compatibility for GSL itself but
> relax this requirement for these two tests and use mkstemp and the MSVC
> equivalent (_mktemp or _mktemp_s) that seem to avoid the problem.
>
> I cant test for these failures however as they don't occur for me as I
> am running the build with admin privileges.
>
>best regards,
>
>  Brian
>
>

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

[Brian Gladman]

I assume that by 'race condition' you mean that any tests running in
parallel would both be using the same file (IIRC "test.dat").

If so, you could possibly revert your change and use the tmpnam()
function to set the filename to be used.

I don't know where the resulting file would be placed with GCC but on
Windows this will return a filename that is unique in the current
working directory, which would be likely to have the right access
permission.  However, the MS documentation simply says that

"tmpnam returns a name unique in the current working directory"

which suggests that this won't solve the race condition.

We could possibly maintain full c89 compatibility for GSL itself but
relax this requirement for these two tests and use mkstemp and the MSVC
equivalent (_mktemp or _mktemp_s) that seem to avoid the problem.

I cant test for these failures however as they don't occur for me as I
am running the build with admin privileges.

   best regards,

 Brian

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

[Mohammad Akhlaghi]

Hi Patrick,

Thanks for the correction. 

So the two tests are identical except for the versions of the functions. Can't 
they also differ in the filename they use? 

For example one could read/write to "test-non-inline.dat" and the other to 
"test-inline.dat".

Cheers,
Mohammad

On June 22, 2017 9:00:22 AM GMT+01:00, Patrick Alken  wrote:
>Its not a race condition between the files written by matrix/vector.
>The
>vector module itself has two test programs, which are identical except
>one tests the non-inline versions of the functions and the other tests
>the inline versions. So if these two tests are run in parallel, via
>make
>check -j8, they will write the same test file name at the same time if
>we use a static filename.
>
>Patrick
>
>On 06/22/2017 09:56 AM, Mohammad Akhlaghi wrote:
>> Hi Patrick,
>>
>> How about using two separate files (file names) for vector and matrix
>> tests?
>>
>> For example "test-vector.dat" and "test-matrix.dat".
>>
>> Cheers,
>> Mohammad
>>
>> On June 22, 2017 8:12:06 AM GMT+01:00, Patrick Alken
>>  wrote:
>>
>> In GSL 2.3 and earlier, the vector and matrix modules tested the
>> fwrite/fread routines by creating temporary files with mkstemp()
>and
>> fdopen(). Unfortunately neither of these routines conform to the
>ANSI
>> C89 standard and so I converted these tests to write to a fixed
>filename
>> "test.dat". However this caused the file race condition which was
>> reported in the recent test candidates (i.e. the "make check -j8"
>> error). So finally I switched to use tmpfile() which is C89 and
>seems to
>> be the only ANSI-compatible method of using temporary files in C.
>But
>> now it seems that some windows systems fail with this method due
>to
>> permission restrictions.
>>
>> I can certainly modify the tests to check for a NULL pointer
>coming out
>> of tmpfile, but this would then disable these tests on your
>windows
>> systems, which is not ideal either. It appears we must either
>accept
>> that the matrix/vector fread/fwrite routines cannot be properly
>tested
>> on windows systems, or go back to a non-ANSI method of writing
>the
>> temporary files. Neither of these choices seem good to me, but my
>> preference would be to follow the C89 standard if possible.
>>
>> I thought about writing a routine inside GSL to perform the same
>task as
>> mkstemp() does, but it seems this is not possible in C89 since
>mkstemp
>> relies on calling open() with O_EXCL to raise an error if the
>file
>> already exists, but open() is also not C89.
>>
>> I am open to suggestions if anyone knows of a solution to this
>problem.
>>
>> Patrick
>>
>> On 06/21/2017 03:26 PM, Max Gaspa wrote:
>>
>> Dear all, Sisyphus wrote
>>
>> Much the same situation here - Windows 7 64 bit,
>mingw-w64
>> port of 64-bit gcc-6.3.0 (x86_64-posix-sjlj-rev1). And,
>> like you (apparently), I didn't test the release
>> candidates :-( 
>>
>> Yes. And Yes. I didn't check the release candidate because
>the
>> short time between the availability of the RC and the
>> availability of the official release. Anyway I think I found
>> the reason of the issue just following the program flow with
>> gdb. The issue is NOT related to malloc(0) (I' still thinking
>> that is not a good programming practice but I will accept it
>> :-) ) I'm discussing the issue for vector just to describe it
>> in a simpler way. The reason of the segmentation fault is the
>> latest modification made by Patrick 7 days ago into
>> test_source.c ( described by "fix file race condition for
>> 'make check -j8'" ). The lines involved are - char filename[]
>> = "test.dat"; + FILE *f = tmpfile(); in few words the change
>> imply using tmpfile(). Unfortunately in Windows (XP is fine!
>7
>> fails) that call is creating a temporary file in C:\ that is
>> usually not writable for security reason. The call fails and
>> the pointer f is NULL. Because there are no checking for NULL
>> after the call to tmpfile() (It seems GSL developer love not
>> checking for null pointer :-) :-) :-) ) and the next call
>> to fprintf will use NULL as its stream you get the
>> segmentation fault. Now I'm trying to revert the change (just
>> using the release candidate version should be fine) to see if
>> the issue is fixed, but I'm quite sure because gdb told me
>> that f was NULL but it was used as a valid pointer for the
>> stream For reference: Microsoft documentation of the C
>runtime
>> library (used by MinGW) for tmpfile() *** The tmpfile()
>> function creates a temporary file and returns a pointer to
>> that stream. The temporary file is created in the root
>> directory. To create a temporary f

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

[Patrick Alken]

Its not a race condition between the files written by matrix/vector. The
vector module itself has two test programs, which are identical except
one tests the non-inline versions of the functions and the other tests
the inline versions. So if these two tests are run in parallel, via make
check -j8, they will write the same test file name at the same time if
we use a static filename.

Patrick

On 06/22/2017 09:56 AM, Mohammad Akhlaghi wrote:
> Hi Patrick,
>
> How about using two separate files (file names) for vector and matrix
> tests?
>
> For example "test-vector.dat" and "test-matrix.dat".
>
> Cheers,
> Mohammad
>
> On June 22, 2017 8:12:06 AM GMT+01:00, Patrick Alken
>  wrote:
>
> In GSL 2.3 and earlier, the vector and matrix modules tested the
> fwrite/fread routines by creating temporary files with mkstemp() and
> fdopen(). Unfortunately neither of these routines conform to the ANSI
> C89 standard and so I converted these tests to write to a fixed filename
> "test.dat". However this caused the file race condition which was
> reported in the recent test candidates (i.e. the "make check -j8"
> error). So finally I switched to use tmpfile() which is C89 and seems to
> be the only ANSI-compatible method of using temporary files in C. But
> now it seems that some windows systems fail with this method due to
> permission restrictions.
>
> I can certainly modify the tests to check for a NULL pointer coming out
> of tmpfile, but this would then disable these tests on your windows
> systems, which is not ideal either. It appears we must either accept
> that the matrix/vector fread/fwrite routines cannot be properly tested
> on windows systems, or go back to a non-ANSI method of writing the
> temporary files. Neither of these choices seem good to me, but my
> preference would be to follow the C89 standard if possible.
>
> I thought about writing a routine inside GSL to perform the same task as
> mkstemp() does, but it seems this is not possible in C89 since mkstemp
> relies on calling open() with O_EXCL to raise an error if the file
> already exists, but open() is also not C89.
>
> I am open to suggestions if anyone knows of a solution to this problem.
>
> Patrick
>
> On 06/21/2017 03:26 PM, Max Gaspa wrote:
>
> Dear all, Sisyphus wrote
>
> Much the same situation here - Windows 7 64 bit, mingw-w64
> port of 64-bit gcc-6.3.0 (x86_64-posix-sjlj-rev1). And,
> like you (apparently), I didn't test the release
> candidates :-( 
>
> Yes. And Yes. I didn't check the release candidate because the
> short time between the availability of the RC and the
> availability of the official release. Anyway I think I found
> the reason of the issue just following the program flow with
> gdb. The issue is NOT related to malloc(0) (I' still thinking
> that is not a good programming practice but I will accept it
> :-) ) I'm discussing the issue for vector just to describe it
> in a simpler way. The reason of the segmentation fault is the
> latest modification made by Patrick 7 days ago into
> test_source.c ( described by "fix file race condition for
> 'make check -j8'" ). The lines involved are - char filename[]
> = "test.dat"; + FILE *f = tmpfile(); in few words the change
> imply using tmpfile(). Unfortunately in Windows (XP is fine! 7
> fails) that call is creating a temporary file in C:\ that is
> usually not writable for security reason. The call fails and
> the pointer f is NULL. Because there are no checking for NULL
> after the call to tmpfile() (It seems GSL developer love not
> checking for null pointer :-) :-) :-) ) and the next call
> to fprintf will use NULL as its stream you get the
> segmentation fault. Now I'm trying to revert the change (just
> using the release candidate version should be fine) to see if
> the issue is fixed, but I'm quite sure because gdb told me
> that f was NULL but it was used as a valid pointer for the
> stream For reference: Microsoft documentation of the C runtime
> library (used by MinGW) for tmpfile() *** The tmpfile()
> function creates a temporary file and returns a pointer to
> that stream. The temporary file is created in the root
> directory. To create a temporary file in a directory other
> than the root, use tmpnam or tempnam in conjunction with
> fopen. If the file cannot be opened, tmpfile returns a NULL
> pointer. This temporary file is automatically deleted when the
> file is closed, when the program terminates normally, or when
> _rmtmp is called, assuming that the current working directory
> does not change. The temporary file is opened in w+b (binary
>

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

[Mohammad Akhlaghi]

Hi Patrick,

How about using two separate files (file names) for vector and matrix tests? 

For example "test-vector.dat" and "test-matrix.dat".

Cheers,
Mohammad

On June 22, 2017 8:12:06 AM GMT+01:00, Patrick Alken  wrote:
>In GSL 2.3 and earlier, the vector and matrix modules tested the
>fwrite/fread routines by creating temporary files with mkstemp() and
>fdopen(). Unfortunately neither of these routines conform to the ANSI
>C89 standard and so I converted these tests to write to a fixed
>filename
>"test.dat". However this caused the file race condition which was
>reported in the recent test candidates (i.e. the "make check -j8"
>error). So finally I switched to use tmpfile() which is C89 and seems
>to
>be the only ANSI-compatible method of using temporary files in C. But
>now it seems that some windows systems fail with this method due to
>permission restrictions.
>
>I can certainly modify the tests to check for a NULL pointer coming out
>of tmpfile, but this would then disable these tests on your windows
>systems, which is not ideal either. It appears we must either accept
>that the matrix/vector fread/fwrite routines cannot be properly tested
>on windows systems, or go back to a non-ANSI method of writing the
>temporary files. Neither of these choices seem good to me, but my
>preference would be to follow the C89 standard if possible.
>
>I thought about writing a routine inside GSL to perform the same task
>as
>mkstemp() does, but it seems this is not possible in C89 since mkstemp
>relies on calling open() with O_EXCL to raise an error if the file
>already exists, but open() is also not C89.
>
>I am open to suggestions if anyone knows of a solution to this problem.
>
>Patrick
>
>On 06/21/2017 03:26 PM, Max Gaspa wrote:
>> Dear all,
>>
>> Sisyphus wrote
>>
>>> Much the same situation here - Windows 7 64 bit, mingw-w64 port of
>64-bit gcc-6.3.0 (x86_64-posix-sjlj-rev1).
>>> And, like you (apparently), I didn't test the release candidates :-(
>> Yes. And Yes. I didn't check the release candidate because the short
>> time between the availability of the RC and the availability of the
>> official release.
>>
>>
>> Anyway I think I found the reason of the issue just following the
>> program flow with gdb. The issue is NOT related to malloc(0) (I'
>still
>> thinking that is not a good programming practice but I will accept it
>> :-) )
>>
>> I'm discussing the issue for vector just to describe it in a simpler
>way.
>>
>> The reason of the segmentation fault is the latest modification made
>> by Patrick 7 days ago into test_source.c  ( described by "fix file
>> race condition for 'make check -j8'" ).
>>
>> The lines involved are
>>
>> - char filename[] = "test.dat";
>> + FILE *f = tmpfile();
>>
>> in few words the change imply using tmpfile(). Unfortunately in
>> Windows (XP is fine! 7 fails) that call is creating a temporary file
>> in C:\ that is usually not writable for security reason. The call
>> fails and the pointer f is NULL. Because there are no checking for
>> NULL after the call to tmpfile()  (It seems GSL developer love not
>> checking for null pointer :-) :-) :-)  ) and the next call to
>> fprintf will use NULL as its stream you get the segmentation fault.
>>
>> Now I'm trying to revert the change (just using the release candidate
>> version should be fine)  to see if the issue is fixed, but I'm quite
>> sure because gdb told me that f  was  NULL but it was used as a valid
>> pointer for the stream
>>
>> For reference:
>>
>> Microsoft documentation of the C runtime library (used by MinGW) for
>tmpfile()
>>
>> ***
>> The tmpfile() function creates a temporary file and returns a pointer
>> to that stream. The temporary file is created in the root directory.
>> To create a temporary file in a directory other than the root, use
>> tmpnam or tempnam in conjunction with fopen.
>>
>> If the file cannot be opened, tmpfile returns a NULL pointer. This
>> temporary file is automatically deleted when the file is closed, when
>> the program terminates normally, or when _rmtmp is called, assuming
>> that the current working directory does not change. The temporary
>file
>> is opened in w+b (binary read/write) mode.
>>
>> Failure can occur if you attempt more than TMP_MAX (see STDIO.H)
>calls
>> with tmpfile.
>>
>> *
>>
>> I'm also observing the error related to the Bessel function like you.
>> I think I know the reason. The GSL developers are now using sin and
>> cos function from the runtime library. Before that change the
>> numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was
>> added to the total error with
>>
>> result->err  = fabs(f * sin_result.err/x) +
>fabs((3.0*cos_result.err/x)/x);
>>
>> in the new code sin and cos were considered as they are perfectly
>> precise (sin and cos precision depends on processor and it's known
>> their precision can be more, much more, greatter than 1 ulp), so the
>> new implementation and the threshold used to pass the test are no
>> longe

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

[Patrick Alken]

> Hello,
>
> what is wrong about using tmpnam + fopen ?
>
> See "Remarks" section in
> https://msdn.microsoft.com/en-us/library/x8x7sakw.aspx
>
> It should solve the problem with placing the file in other path than
> root directory. According to linux manpages, both tmpnam and fopen
> should be C89 compatible.
> https://msdn.microsoft.com/de-de/subscriptions/hs3e7355(v=vs.80).aspx
> states it is ANSI compatible implementation available since Windows 95.
>
> David
>
Yes I should have clarified before, tmpnam() is a possible alternative,
however it is generally recommended to avoid this function.

For example, see
https://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html

Quote:

Warning: Between the time the pathname is constructed and the file is
created another process might have created a file with the same name
using tmpnam, leading to a possible security hole. The implementation
generates names which can hardly be predicted, but when opening the file
you should use the O_EXCL flag. Using tmpfile or mkstemp is a safe way
to avoid this problem.


So I should have said that tmpfile() appears to be the only ANSI C89
method of using temporary files which is thread-safe and also does not
contain the security vulnerability described above. The Linux man page
for tmpnam() also includes this:


BUGS
   Never use this function.  Use mkstemp(3) or tmpfile(3) instead.

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

[David Komanek]

On 06/22/2017 09:12 AM, Patrick Alken wrote:
> In GSL 2.3 and earlier, the vector and matrix modules tested the
> fwrite/fread routines by creating temporary files with mkstemp() and
> fdopen(). Unfortunately neither of these routines conform to the ANSI
> C89 standard and so I converted these tests to write to a fixed filename
> "test.dat". However this caused the file race condition which was
> reported in the recent test candidates (i.e. the "make check -j8"
> error). So finally I switched to use tmpfile() which is C89 and seems to
> be the only ANSI-compatible method of using temporary files in C. But
> now it seems that some windows systems fail with this method due to
> permission restrictions.
>
> I can certainly modify the tests to check for a NULL pointer coming out
> of tmpfile, but this would then disable these tests on your windows
> systems, which is not ideal either. It appears we must either accept
> that the matrix/vector fread/fwrite routines cannot be properly tested
> on windows systems, or go back to a non-ANSI method of writing the
> temporary files. Neither of these choices seem good to me, but my
> preference would be to follow the C89 standard if possible.
>
> I thought about writing a routine inside GSL to perform the same task as
> mkstemp() does, but it seems this is not possible in C89 since mkstemp
> relies on calling open() with O_EXCL to raise an error if the file
> already exists, but open() is also not C89.
>
> I am open to suggestions if anyone knows of a solution to this problem.

Hello,

what is wrong about using tmpnam + fopen ?

See "Remarks" section in
https://msdn.microsoft.com/en-us/library/x8x7sakw.aspx

It should solve the problem with placing the file in other path than
root directory. According to linux manpages, both tmpnam and fopen
should be C89 compatible.
https://msdn.microsoft.com/de-de/subscriptions/hs3e7355(v=vs.80).aspx
states it is ANSI compatible implementation available since Windows 95.

David



>
> Patrick
>
> On 06/21/2017 03:26 PM, Max Gaspa wrote:
>> Dear all,
>>
>> Sisyphus wrote
>>
>>> Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit 
>>> gcc-6.3.0 (x86_64-posix-sjlj-rev1).
>>> And, like you (apparently), I didn't test the release candidates :-(
>> Yes. And Yes. I didn't check the release candidate because the short
>> time between the availability of the RC and the availability of the
>> official release.
>>
>>
>> Anyway I think I found the reason of the issue just following the
>> program flow with gdb. The issue is NOT related to malloc(0) (I' still
>> thinking that is not a good programming practice but I will accept it
>> :-) )
>>
>> I'm discussing the issue for vector just to describe it in a simpler way.
>>
>> The reason of the segmentation fault is the latest modification made
>> by Patrick 7 days ago into test_source.c  ( described by "fix file
>> race condition for 'make check -j8'" ).
>>
>> The lines involved are
>>
>> - char filename[] = "test.dat";
>> + FILE *f = tmpfile();
>>
>> in few words the change imply using tmpfile(). Unfortunately in
>> Windows (XP is fine! 7 fails) that call is creating a temporary file
>> in C:\ that is usually not writable for security reason. The call
>> fails and the pointer f is NULL. Because there are no checking for
>> NULL after the call to tmpfile()  (It seems GSL developer love not
>> checking for null pointer :-) :-) :-)  ) and the next call to
>> fprintf will use NULL as its stream you get the segmentation fault.
>>
>> Now I'm trying to revert the change (just using the release candidate
>> version should be fine)  to see if the issue is fixed, but I'm quite
>> sure because gdb told me that f  was  NULL but it was used as a valid
>> pointer for the stream
>>
>> For reference:
>>
>> Microsoft documentation of the C runtime library (used by MinGW) for 
>> tmpfile()
>>
>> ***
>> The tmpfile() function creates a temporary file and returns a pointer
>> to that stream. The temporary file is created in the root directory.
>> To create a temporary file in a directory other than the root, use
>> tmpnam or tempnam in conjunction with fopen.
>>
>> If the file cannot be opened, tmpfile returns a NULL pointer. This
>> temporary file is automatically deleted when the file is closed, when
>> the program terminates normally, or when _rmtmp is called, assuming
>> that the current working directory does not change. The temporary file
>> is opened in w+b (binary read/write) mode.
>>
>> Failure can occur if you attempt more than TMP_MAX (see STDIO.H) calls
>> with tmpfile.
>>
>> *
>>
>> I'm also observing the error related to the Bessel function like you.
>> I think I know the reason. The GSL developers are now using sin and
>> cos function from the runtime library. Before that change the
>> numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was
>> added to the total error with
>>
>> result->err  = fabs(f * sin_result.err/x) + fabs((3.0*cos_result.err/x)/x);

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

[Patrick Alken]

In GSL 2.3 and earlier, the vector and matrix modules tested the
fwrite/fread routines by creating temporary files with mkstemp() and
fdopen(). Unfortunately neither of these routines conform to the ANSI
C89 standard and so I converted these tests to write to a fixed filename
"test.dat". However this caused the file race condition which was
reported in the recent test candidates (i.e. the "make check -j8"
error). So finally I switched to use tmpfile() which is C89 and seems to
be the only ANSI-compatible method of using temporary files in C. But
now it seems that some windows systems fail with this method due to
permission restrictions.

I can certainly modify the tests to check for a NULL pointer coming out
of tmpfile, but this would then disable these tests on your windows
systems, which is not ideal either. It appears we must either accept
that the matrix/vector fread/fwrite routines cannot be properly tested
on windows systems, or go back to a non-ANSI method of writing the
temporary files. Neither of these choices seem good to me, but my
preference would be to follow the C89 standard if possible.

I thought about writing a routine inside GSL to perform the same task as
mkstemp() does, but it seems this is not possible in C89 since mkstemp
relies on calling open() with O_EXCL to raise an error if the file
already exists, but open() is also not C89.

I am open to suggestions if anyone knows of a solution to this problem.

Patrick

On 06/21/2017 03:26 PM, Max Gaspa wrote:
> Dear all,
>
> Sisyphus wrote
>
>> Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit 
>> gcc-6.3.0 (x86_64-posix-sjlj-rev1).
>> And, like you (apparently), I didn't test the release candidates :-(
> Yes. And Yes. I didn't check the release candidate because the short
> time between the availability of the RC and the availability of the
> official release.
>
>
> Anyway I think I found the reason of the issue just following the
> program flow with gdb. The issue is NOT related to malloc(0) (I' still
> thinking that is not a good programming practice but I will accept it
> :-) )
>
> I'm discussing the issue for vector just to describe it in a simpler way.
>
> The reason of the segmentation fault is the latest modification made
> by Patrick 7 days ago into test_source.c  ( described by "fix file
> race condition for 'make check -j8'" ).
>
> The lines involved are
>
> - char filename[] = "test.dat";
> + FILE *f = tmpfile();
>
> in few words the change imply using tmpfile(). Unfortunately in
> Windows (XP is fine! 7 fails) that call is creating a temporary file
> in C:\ that is usually not writable for security reason. The call
> fails and the pointer f is NULL. Because there are no checking for
> NULL after the call to tmpfile()  (It seems GSL developer love not
> checking for null pointer :-) :-) :-)  ) and the next call to
> fprintf will use NULL as its stream you get the segmentation fault.
>
> Now I'm trying to revert the change (just using the release candidate
> version should be fine)  to see if the issue is fixed, but I'm quite
> sure because gdb told me that f  was  NULL but it was used as a valid
> pointer for the stream
>
> For reference:
>
> Microsoft documentation of the C runtime library (used by MinGW) for tmpfile()
>
> ***
> The tmpfile() function creates a temporary file and returns a pointer
> to that stream. The temporary file is created in the root directory.
> To create a temporary file in a directory other than the root, use
> tmpnam or tempnam in conjunction with fopen.
>
> If the file cannot be opened, tmpfile returns a NULL pointer. This
> temporary file is automatically deleted when the file is closed, when
> the program terminates normally, or when _rmtmp is called, assuming
> that the current working directory does not change. The temporary file
> is opened in w+b (binary read/write) mode.
>
> Failure can occur if you attempt more than TMP_MAX (see STDIO.H) calls
> with tmpfile.
>
> *
>
> I'm also observing the error related to the Bessel function like you.
> I think I know the reason. The GSL developers are now using sin and
> cos function from the runtime library. Before that change the
> numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was
> added to the total error with
>
> result->err  = fabs(f * sin_result.err/x) + fabs((3.0*cos_result.err/x)/x);
>
> in the new code sin and cos were considered as they are perfectly
> precise (sin and cos precision depends on processor and it's known
> their precision can be more, much more, greatter than 1 ulp), so the
> new implementation and the threshold used to pass the test are no
> longer OK for my (and your) processor.
>
> I'd like to change the compilation flags (using SSE2 and or
> -mfloat-store) just to see what will happen...and then using MPFR I'd
> like to understand better the reason of the failure.
>
> Hope this helps
>
> Regards
>
> Max
>

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

[sisyphus1]

-Original Message- 
From: Max Gaspa

Sent: Wednesday, June 21, 2017 11:26 PM
To: help-gsl@gnu.org
Subject: Re: [Help-gsl] test release for GSL 2.4

[snip]


- char filename[] = "test.dat";
+ FILE *f = tmpfile();

in few words the change imply using tmpfile(). Unfortunately in Windows 
(XP is fine! 7 fails) that call is creating a temporary file in C:\ that 
is usually not writable for security reason. The call fails and the 
pointer f is NULL.


Interestingly, while the call fails with my 64-bit gcc-6.3.0, it succeeds 
with the 32-bit gcc-6.3.0. At least, f is not NULL - though it seems that 
the file is un-writeable.
Presumably this accounts for the difference in the behaviour between my 
32-bit and 64-bit builds.


[snip]

I'd like to change the compilation flags (using SSE2 and or -mfloat-store) 
just to see what will happen...and then using MPFR I'd like to understand 
better the reason of the failure.


The manual says that gsl_sf_bessel_j2_e() computes ((3/x^2 - 1) * sin(x) - 3 
* cos(x)/x)/x
Using MPFR (with a sufficiently large precision) shows that the *exact* 
value of that computation (for x = 1048576.0), rounded to 17 decimal digits 
is -3.1518539455252413e-007.


When I perform that calculation (with double precision) using 64-bit 
gcc-6.3.0, I get a result of -3.1518539455252539e-007.

This is the value "obtained" in the test-suite.log - and it's simply wrong.

Using MPFR, I find that performing that calculation with double (53-bit) 
precision, gives -3.1518539455252417e-7.


The culprit for the error is, of course, the gcc-6.3.0 trig functions. For 
1048576.0, according to gcc-6.3.0:


sin: 3.3049314002173596e-001
cos: 9.4380839390131155e-001

According to MPFR:

sin: 3.3049314002173469e-1
cos: 9.4380839390131199e-1

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.


mpfr_jn() returns a completely different value for the value 1048576.0 (n = 
2).

I'm getting -7.02097920391228138906e-4.
I guess (hope) that it's a different function to gsl_sf_bessel_j2_e().

Cheers,
Rob

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

[ƦOB COASTN]

Greeetings All,

Let Appveyor attest to the "HEAP CORRUPTION DETECTED".
https://ci.appveyor.com/project/mancoast/gsl-msvc/build/1.0.1.0.0.7.8-master
TestMatrix.exe && TestVector.exe Failed. [See Attached Screenshot]

Thanks,
coast

On Wed, Jun 21, 2017 at 9:26 AM, Max Gaspa  wrote:
> Dear all,
>
> Sisyphus wrote
>
>>Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit 
>>gcc-6.3.0 (x86_64-posix-sjlj-rev1).
>>And, like you (apparently), I didn't test the release candidates :-(
>
> Yes. And Yes. I didn't check the release candidate because the short
> time between the availability of the RC and the availability of the
> official release.
>
>
> Anyway I think I found the reason of the issue just following the
> program flow with gdb. The issue is NOT related to malloc(0) (I' still
> thinking that is not a good programming practice but I will accept it
> :-) )
>
> I'm discussing the issue for vector just to describe it in a simpler way.
>
> The reason of the segmentation fault is the latest modification made
> by Patrick 7 days ago into test_source.c  ( described by "fix file
> race condition for 'make check -j8'" ).
>
> The lines involved are
>
> - char filename[] = "test.dat";
> + FILE *f = tmpfile();
>
> in few words the change imply using tmpfile(). Unfortunately in
> Windows (XP is fine! 7 fails) that call is creating a temporary file
> in C:\ that is usually not writable for security reason. The call
> fails and the pointer f is NULL. Because there are no checking for
> NULL after the call to tmpfile()  (It seems GSL developer love not
> checking for null pointer :-) :-) :-)  ) and the next call to
> fprintf will use NULL as its stream you get the segmentation fault.
>
> Now I'm trying to revert the change (just using the release candidate
> version should be fine)  to see if the issue is fixed, but I'm quite
> sure because gdb told me that f  was  NULL but it was used as a valid
> pointer for the stream
>
> For reference:
>
> Microsoft documentation of the C runtime library (used by MinGW) for tmpfile()
>
> ***
> The tmpfile() function creates a temporary file and returns a pointer
> to that stream. The temporary file is created in the root directory.
> To create a temporary file in a directory other than the root, use
> tmpnam or tempnam in conjunction with fopen.
>
> If the file cannot be opened, tmpfile returns a NULL pointer. This
> temporary file is automatically deleted when the file is closed, when
> the program terminates normally, or when _rmtmp is called, assuming
> that the current working directory does not change. The temporary file
> is opened in w+b (binary read/write) mode.
>
> Failure can occur if you attempt more than TMP_MAX (see STDIO.H) calls
> with tmpfile.
>
> *
>
> I'm also observing the error related to the Bessel function like you.
> I think I know the reason. The GSL developers are now using sin and
> cos function from the runtime library. Before that change the
> numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was
> added to the total error with
>
> result->err  = fabs(f * sin_result.err/x) + fabs((3.0*cos_result.err/x)/x);
>
> in the new code sin and cos were considered as they are perfectly
> precise (sin and cos precision depends on processor and it's known
> their precision can be more, much more, greatter than 1 ulp), so the
> new implementation and the threshold used to pass the test are no
> longer OK for my (and your) processor.
>
> I'd like to change the compilation flags (using SSE2 and or
> -mfloat-store) just to see what will happen...and then using MPFR I'd
> like to understand better the reason of the failure.
>
> Hope this helps
>
> Regards
>
> Max
>

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

[Max Gaspa]

Dear all,

Sisyphus wrote

>Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit 
>gcc-6.3.0 (x86_64-posix-sjlj-rev1).
>And, like you (apparently), I didn't test the release candidates :-(

Yes. And Yes. I didn't check the release candidate because the short
time between the availability of the RC and the availability of the
official release.


Anyway I think I found the reason of the issue just following the
program flow with gdb. The issue is NOT related to malloc(0) (I' still
thinking that is not a good programming practice but I will accept it
:-) )

I'm discussing the issue for vector just to describe it in a simpler way.

The reason of the segmentation fault is the latest modification made
by Patrick 7 days ago into test_source.c  ( described by "fix file
race condition for 'make check -j8'" ).

The lines involved are

- char filename[] = "test.dat";
+ FILE *f = tmpfile();

in few words the change imply using tmpfile(). Unfortunately in
Windows (XP is fine! 7 fails) that call is creating a temporary file
in C:\ that is usually not writable for security reason. The call
fails and the pointer f is NULL. Because there are no checking for
NULL after the call to tmpfile()  (It seems GSL developer love not
checking for null pointer :-) :-) :-)  ) and the next call to
fprintf will use NULL as its stream you get the segmentation fault.

Now I'm trying to revert the change (just using the release candidate
version should be fine)  to see if the issue is fixed, but I'm quite
sure because gdb told me that f  was  NULL but it was used as a valid
pointer for the stream

For reference:

Microsoft documentation of the C runtime library (used by MinGW) for tmpfile()

***
The tmpfile() function creates a temporary file and returns a pointer
to that stream. The temporary file is created in the root directory.
To create a temporary file in a directory other than the root, use
tmpnam or tempnam in conjunction with fopen.

If the file cannot be opened, tmpfile returns a NULL pointer. This
temporary file is automatically deleted when the file is closed, when
the program terminates normally, or when _rmtmp is called, assuming
that the current working directory does not change. The temporary file
is opened in w+b (binary read/write) mode.

Failure can occur if you attempt more than TMP_MAX (see STDIO.H) calls
with tmpfile.

*

I'm also observing the error related to the Bessel function like you.
I think I know the reason. The GSL developers are now using sin and
cos function from the runtime library. Before that change the
numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was
added to the total error with

result->err  = fabs(f * sin_result.err/x) + fabs((3.0*cos_result.err/x)/x);

in the new code sin and cos were considered as they are perfectly
precise (sin and cos precision depends on processor and it's known
their precision can be more, much more, greatter than 1 ulp), so the
new implementation and the threshold used to pass the test are no
longer OK for my (and your) processor.

I'd like to change the compilation flags (using SSE2 and or
-mfloat-store) just to see what will happen...and then using MPFR I'd
like to understand better the reason of the failure.

Hope this helps

Regards

Max

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

[sisyphus1]

-Original Message- 
From: maxgacode

Sent: Wednesday, June 21, 2017 7:02 AM
To: help-gsl@gnu.org
Subject: Re: [Help-gsl] test release for GSL 2.4


Il 15/06/2017 10:27, Patrick Alken ha scritto:

Hi all,

   There is now a new test release here:

ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig


I'm trying to compile GSL 2.4 but I'm observing a lot of serious issues.

Platform Windows 7 64 bit latest SP.
MinGW64 with GCC 6.1.0


Hi Max,

Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit 
gcc-6.3.0 (x86_64-posix-sjlj-rev1).

And, like you (apparently), I didn't test the release candidates :-(

Attached are my vector/test-suite.log and matrix/test-suite.log.
Do you get the same ?

Interestingly, things are a little different using a mingw-w64 port of 
32-bit gcc-6.3.0 (i686-posix-sjlj-rev1).


Firstly, the matrix tests pass.

Secondly, althought the vector tests still fail (and still with a segfault), 
the error reported in the test-suit.log is different:


gsl: fwrite_source.c:96: ERROR: fwrite failed
Default GSL error handler invoked.

Only other failure I've noticed is a test failure in specfunc. The log for 
it is also attached. (It's the same log for both 32-bit and 64-bit builds.)


Cheers,
Rob


vector-test-suite.log
Description: Binary data


specfunc-test-suite.log
Description: Binary data


matrix-test-suite.log
Description: Binary data

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

[maxgacode]

Il 15/06/2017 10:27, Patrick Alken ha scritto:

Hi all,

   There is now a new test release here:

ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig



I'm trying to compile GSL 2.4 but I'm observing a lot of serious issues.

Platform Windows 7 64 bit latest SP.
MinGW64 with GCC 6.1.0

Using the same platform and compiler I successfully compiled GSL 2.3 
without any issues using both optimization and debugging options.


I'd like to start with the most important issue. I'm observing several 
sistematic "segmentatio fault" in both vector and matrix tests.


At the moment I'm trying to understand better the issue but I have a doubt.

In the past a "bug" was reported (bug #49988) related to a "follow the 
style of malloc and free" documentation imprecision.


To fix that "imprecision" GSL added the support for  "zero-length objects"

Ok now from facts to my guess

Reading the source code I understood that in the end you are doing 
something like


malloc(0)

a thing the "should never be done" (as I've been told during my C course 
at University).


Ok, having passed the time that may be done today..but my guess is 
still that malloc(0) shuold never be done.


Looking at ISO/IEC 9899:1999


7.20.3 Memory management functions

.. If the size of the space requested is zero, the behavior is 
implementation-defined: either a null pointer is returned, or the 
behavior is as if the size were some nonzero value, except that the 
returned pointer shall not be used to access an object.


and in ISO/IEC 9899:201x

7.22.3 Memory management functions

If the space cannot be allocated, a null pointer is returned. If the 
size of the space requested is zero, the behavior is 
implementation-defined: either a null pointer is returned, or the 
behavior is as if the size were some nonzero value, except that the 
returned pointer shall not be used to access an object.


You can call free but not deferencing the pointer.

So adding "zero-length objects" had (in my opinion) made GSL no longer 
portable, implementation defined or even worse unspecified in some 
implementation.


In fact in both standard you can also find the following reason for an 
unspecified behavior



Section J

- The amount of storage allocated by a successful call to the calloc, 
malloc, or realloc function when 0 bytes was requested (7.20.3).



May be in some (or most) platform works but it seems quite strange to me 
to consider an "unspecified behavior" acceptable just to correct a minor 
imprecision of the documentation. IMHO is better to change the 
documentation


Is really useful in the "real life" to allocate a zero lenght vector? I 
prefer to get an assertion (calling an error handler) of problem becasue 
usually (IMHO) a malloc(0) is due to a buggy code. A malloc(0) may 
returns a non NULL pointer to a block of zero byte memmoryat that 
point you can deferencing it..


My current guess is that I'm observing a segmentation fault as a result 
of a malloc(0) but I may be wrong and I'm still investigating the issue, 
but in any case I'm wondering if a "revert" may be better for GSL.



I'd like to know your opinion.

As a further reference look at the book

The CERT C Secure Coding Standard
By Robert C. Seacord


Regards

Max

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

[Adam Majer]

On 06/15/2017 10:27 AM, Patrick Alken wrote:
> Hi all,
> 
>   There is now a new test release here:
> 
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig
> 
> The parallel issue (make check -j8) should be fixed. Also the
> documentation should build now. I'd appreciate if people could re-test.
> I've repeated the instructions below.
> 
> Please try testing the build:
> 
> ./configure && make && make check


It seems it is building correctly on almost all architectures. Except
32-bit Intel. 32-bit port of Tumbleweed (which uses GCC 7.1.1)

[  267s] ./specfunc/test.log
[  267s] FAIL: identity1 phys n=7 x=2.88 y=-3.2 (431.965255195457871
observed vs 431.965255195689167 expected) [1722]
[  267s] FAIL test (exit status: 1)
[  267s] ./specfunc/test-suite.log

But the failure seems to be the same as with GCC 4.8 (the SLE12 SP2
version on unsupported 32-bit architecture)

[  225s] ./specfunc/test.log
[  225s] FAIL: identity1 phys n=7 x=2.88 y=-3.2 (431.965255195457871
observed vs 431.965255195689167 expected) [1722]


For complete build logs,

https://build.opensuse.org/package/show/home:adamm:branches:science/gsl


Best regards,
Adam

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

[Piotr Tryniecki]

Hello Patrick

Build again succesfull.

Debian GNU/Linux testing "Stretch" - Official Snapshot i386 20161003-05:38
gcc version 6.2.0 20161010 (Debian 6.2.0-6)

Build doc also successfull.

Thanks for Your involvement and good job.

Regards

Piotr



W dniu 2017-06-15 10:27:11 użytkownik Patrick Alken  
napisał:
> Hi all,
> 
>   There is now a new test release here:
> 
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig
> 
> The parallel issue (make check -j8) should be fixed. Also the
> documentation should build now. I'd appreciate if people could re-test.
> I've repeated the instructions below.
> 
> Please try testing the build:
> 
> ./configure && make && make check
> 
> The documentation has now been migrated from texinfo to the python-based
> sphinx software. If you wish you can test building the documentation,
> but you will need to install the sphinx software first:
> 
> 1. pip install -U --user Sphinx
> 
> 2. pip install -U --user sphinx_rtd_theme
> 
> (the --user flag will install in your home directory rather than
> system-wide)
> 
> 3. cd doc ; make html
> 
> Please report any successes/failures.
> 
> Thanks,
> Patrick
> 
> 
> 

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

[Brijesh Upadhaya]

Hi! Patrick,

The make build was again successful for the new test release on my system
(LinuxMint 18.1 Serena, x86_64, GCC 5.3.1, GNU C Library 2.23).

Kind regards,
Brijesh

On Thu, Jun 15, 2017 at 11:27 AM, Patrick Alken  wrote:

> Hi all,
>
>   There is now a new test release here:
>
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig
>
> The parallel issue (make check -j8) should be fixed. Also the
> documentation should build now. I'd appreciate if people could re-test.
> I've repeated the instructions below.
>
> Please try testing the build:
>
> ./configure && make && make check
>
> The documentation has now been migrated from texinfo to the python-based
> sphinx software. If you wish you can test building the documentation,
> but you will need to install the sphinx software first:
>
> 1. pip install -U --user Sphinx
>
> 2. pip install -U --user sphinx_rtd_theme
>
> (the --user flag will install in your home directory rather than
> system-wide)
>
> 3. cd doc ; make html
>
> Please report any successes/failures.
>
> Thanks,
> Patrick
>
>
>

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

[Kenneth Geisshirt]

On Thu, 15 Jun 2017 10:27:11 +0200,Patrick Alken wrote:

>  There is now a new test release here:

>ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz

Builds and all tests pass on macOS 10.12.5 using Apple's gcc frontend (Apple 
LLVM version 8.1.0 (clang-802.0.42)). I did see some warning about fabs().

- kneth

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

[Arun Isaac]

>   There is now a new test release here:
>
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig
>
> The parallel issue (make check -j8) should be fixed. Also the
> documentation should build now. I'd appreciate if people could re-test.
>
> Please try testing the build:

I'm on GuixSD with GCC 5.4.0 and Sphinx 1.5.1.

> ./configure && make && make check

Successful. Successful with `make -j2 check' as well.

> 3. cd doc ; make html

Successful too.

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

[Mohammad Akhlaghi]

Thanks Patrick,

The build and tests of GSL 2.3.91 all passed on multiple threads on my 
system (same as before) too.


Thanks for the correction and all the great work on GSL, I am looking 
forward to the 2.4 release.


Cheers,
Mohammad

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

[viktor drobot]

Hello! Tried to rebuild on Arch Linux 64 bit / GCC 7.1.1 / GLIBC 2.25 with
8 threads (-j8 during make) - all builds fine! Documentation now build too!
Thank you for your job!

2017-06-15 11:27 GMT+03:00 Patrick Alken :

> Hi all,
>
>   There is now a new test release here:
>
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig
>
> The parallel issue (make check -j8) should be fixed. Also the
> documentation should build now. I'd appreciate if people could re-test.
> I've repeated the instructions below.
>
> Please try testing the build:
>
> ./configure && make && make check
>
> The documentation has now been migrated from texinfo to the python-based
> sphinx software. If you wish you can test building the documentation,
> but you will need to install the sphinx software first:
>
> 1. pip install -U --user Sphinx
>
> 2. pip install -U --user sphinx_rtd_theme
>
> (the --user flag will install in your home directory rather than
> system-wide)
>
> 3. cd doc ; make html
>
> Please report any successes/failures.
>
> Thanks,
> Patrick
>
>
>


-- 
С уважением,
Дробот Виктор

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

[David Komanek]

On 06/15/2017 10:27 AM, Patrick Alken wrote:
> Hi all,
>
>   There is now a new test release here:
>
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig
>
> The parallel issue (make check -j8) should be fixed. Also the
> documentation should build now. I'd appreciate if people could re-test.
> I've repeated the instructions below.
>
> Please try testing the build:
>
> ./configure && make && make check

Hi,

works well for me on amd64 distros:

Distributor ID:Debian
Description:Debian GNU/Linux 8.8 (jessie)
Release:8.8
Codename:jessie

LSB Version::core-4.1-amd64:core-4.1-noarch
Distributor ID:CentOS
Description:CentOS Linux release 7.3.1611 (Core)
Release:7.3.1611
Codename:Core


Regards,

  David

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

[Patrick Alken]

Hi all,

  There is now a new test release here:

ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz
ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.91.tar.gz.sig

The parallel issue (make check -j8) should be fixed. Also the
documentation should build now. I'd appreciate if people could re-test.
I've repeated the instructions below.

Please try testing the build:

./configure && make && make check

The documentation has now been migrated from texinfo to the python-based
sphinx software. If you wish you can test building the documentation,
but you will need to install the sphinx software first:

1. pip install -U --user Sphinx

2. pip install -U --user sphinx_rtd_theme

(the --user flag will install in your home directory rather than
system-wide)

3. cd doc ; make html

Please report any successes/failures.

Thanks,
Patrick

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

[Piotr Tryniecki]

Hello Patrick

Build succesfull.

Debian GNU/Linux testing "Stretch" - Official Snapshot i386 20161003-05:38
gcc version 6.2.0 20161010 (Debian 6.2.0-6)

Regards

Piotr





W dniu 2017-06-14 13:29:37 użytkownik Patrick Alken  
napisał:
> Dear all,
> 
>   I would like to release the next version of GSL (2.4) since there have
> been some new features added and the usual bug fixes. I have uploaded a
> test release to:
> 
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.90.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.90.tar.gz.sig
> 
> All reports are welcome - anyone who can test on various platforms would
> be appreciated (Linux, BSD, Mac OS, Windows).
> 
> Please try testing the build:
> 
> ./configure && make && make check
> 
> The documentation has now been migrated from texinfo to the python-based
> sphinx software. If you wish you can test building the documentation,
> but you will need to install the sphinx software first:
> 
> 1. pip install -U --user Sphinx
> 
> 2. pip install -U --user sphinx_rtd_theme
> 
> (the --user flag will install in your home directory rather than
> system-wide)
> 
> 3. cd doc ; make html
> 
> Please report any successes/failures.
> 
> Thanks,
> Patrick
> 
> 
> 

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

[Brijesh Upadhaya]

Hi! Patrick

The make build was successful on my system (LinuxMint 18.1 Serena, x86_64,
GCC 5.3.1, GNU C Library 2.23).

Nice work though,
I really appreciate the effort of the whole GSL team.


Kind regards,
Brijesh

On Wed, Jun 14, 2017 at 2:29 PM, Patrick Alken  wrote:

> Dear all,
>
>   I would like to release the next version of GSL (2.4) since there have
> been some new features added and the usual bug fixes. I have uploaded a
> test release to:
>
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.90.tar.gz
> ftp://alpha.gnu.org/gnu/gsl/gsl-2.3.90.tar.gz.sig
>
> All reports are welcome - anyone who can test on various platforms would
> be appreciated (Linux, BSD, Mac OS, Windows).
>
> Please try testing the build:
>
> ./configure && make && make check
>
> The documentation has now been migrated from texinfo to the python-based
> sphinx software. If you wish you can test building the documentation,
> but you will need to install the sphinx software first:
>
> 1. pip install -U --user Sphinx
>
> 2. pip install -U --user sphinx_rtd_theme
>
> (the --user flag will install in your home directory rather than
> system-wide)
>
> 3. cd doc ; make html
>
> Please report any successes/failures.
>
> Thanks,
> Patrick
>
>
>

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

[Arun Isaac]

> That file bspline/Makefile.in should be included in the package

I extracted the tarball again and it worked. Something must have gone
wrong with untarring earlier. Sorry for the noise.

> ./configure && make && make check

Works fine on my GNU GuixSD system with gcc 5.4.0. As already noted,
parallel tests with `make -j2 check' fails.

> 3. cd doc ; make html

Fails with the following:

Making html in .
make[1]: Entering directory '/tmp/gsl-2.3.90/doc'
make[1]: Nothing to be done for 'html-am'.
make[1]: Leaving directory '/tmp/gsl-2.3.90/doc'
Making html in examples
make[1]: Entering directory '/tmp/gsl-2.3.90/doc/examples'
make[1]: Nothing to be done for 'html'.
make[1]: Leaving directory '/tmp/gsl-2.3.90/doc/examples'
Error: Config directory doesn't contain a conf.py file.

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

[Patrick Alken]

oops, I forgot to add the doc source files to the distribution tarball.
I will make a new test release soon

On 06/14/2017 04:22 PM, viktor drobot wrote:
> Hello!
> ./configure && make && make check
> works fine on my system (Arch Linux, GCC 7.1.1, GLIBC 2.25)
>
> However,
> cd doc && make html
> fails with the following error:
> [viktor@freesky-lab ~/test/gsl-2.3.90/doc]$ LANG=C make html
> Making html in .
> make[1]: Entering directory '/home/viktor/test/gsl-2.3.90/doc'
> make[1]: Nothing to be done for 'html-am'.
> make[1]: Leaving directory '/home/viktor/test/gsl-2.3.90/doc'
> Making html in examples
> make[1]: Entering directory '/home/viktor/test/gsl-2.3.90/doc/examples'
> make[1]: Nothing to be done for 'html'.
> make[1]: Leaving directory '/home/viktor/test/gsl-2.3.90/doc/examples'
> Error: Config directory doesn't contain a conf.py file.
> make: *** [Makefile:835: html] Error 1
>
>
> 2017-06-14 17:19 GMT+03:00 Patrick Alken  >:
>
> Thanks Mohammad,
>
>   This is due to a file race condition I inadvertently introduced when
> trying to make those tests C89 compliant. I have uploaded a fix to the
> git, and will make a new test candidate release in a day or so, after
> getting more feedback.
>
>   I've sometimes wondered whether I should group all the GSL tests
> together into one Makefile, so that the summary output gives all the
> test statistics, rather than individual outputs for each module.
> I'm not
> sure which design is better, and haven't seen much information about
> this in the automake documentation.
>
> Patrick
>
> On 06/14/2017 03:03 PM, Mohammad Akhlaghi wrote:
> > Hi Patrick,
> >
> > The `./configure', `make', and `make check' commands ran
> successfully
> > on my system (Arch Linux, GCC 7.1.1, GNU C Library 2.25).
> >
> > To speed up the build, I usually run the Make commands with `-j8' to
> > build in parallel on 8 threads on this system. `make -j8' worked
> > nicely and everything was built. But when I ran `make check -j8',
> > there was a segmentation fault for the `vector' tests (in P.S.).
> So I
> > removed the `-j8' and all tests passed. This is probably due to
> > dependencies in a multi-threaded check (where the tests are built at
> > the same time, not after each other).
> >
> > So, I had a look at `vector/Makefile.am'. It shows that indeed no
> > dependencies are defined for these tests. We had the same issue in
> > Gnuastro's `make check' and was able to solve it using an
> intermediate
> > script to run the built programs (and thus not including
> > `$(check_PROGRAMS)' in `TESTS'.
> >
> > In the link below you can see Gnuastro's `tests/Makefile.am' (we
> have
> > merged all the tests of all the programs/libraries into one
> Makefile).
> > In particular, you can see the part under the "Library checks" title
> > (line 194) and its comments.
> >
> >
> http://git.savannah.gnu.org/cgit/gnuastro.git/tree/tests/Makefile.am
> 
> >
> > The `multithread.c' test program depends on the output of
> another test
> > (`mkprof/mosaic1.sh'). So we have not put `$(check_PROGRAMS)' in
> > `TESTS' and instead defined a small script (`lib/multithread.sh')
> > which depends on the output of the dependent test
> > (`mkprof/mosaic1.sh.log', line 207).
> >
> > Ofcourse, in the current architecture, GSL's tests are not
> unified in
> > one `Makefile.am', but are distributed over separate files with a
> > handful of (sometimes only one) test(s) in each. So running the
> tests
> > in parallel will not significantly improve the speed. But to avoid
> > confusion in cases like this, it can good to define dependencies
> like
> > this so those tests that depend on others don't fail.
> >
> > Thank you very much,
> > Mohammad
> >
> >
> > P.S.
> >
> > make[2]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> > make[3]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> > ../test-driver: line 95: 32689 Segmentation fault  (core dumped)
> > "$@" > $log_file 2>&1
> > FAIL: test_static
> > PASS: test
> > make[4]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> > make[4]: Nothing to be done for 'all'.
> > make[4]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> >
> 
> 
> >
> > Testsuite summary for gsl 2.3.90
> >
> 
> 
> >
> > # TOTAL: 2
> > # PASS:  1
> > # SKIP:  0
> > # XFAIL: 0
> > # FAIL:  1
> > # XPASS: 0
> > # ERROR: 0
> >
> 
> =

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

[Vale Cofer-Shabica]

Hi Patrick,

Thank you for all the work you do for this package!

I have the following to report:

SUCCESS:
Up-to date x86_64 Arch Linux machine: gcc 7.1.1, glibc 2.25

TEST FAILURES:
Ancient x86_64 Rocks 4.3 cluster (based on 2007 era centos): Linux 2.6.18
gcc 4.4.4, glibc2.4
specfunc failed
2010-era power-pc cluster: Linux 2.6.32, gcc 4.4.7, glibc 2.12
linalg failed

COMPILE FAILURE:
Same 2010-era cluster using the cross-compilation wrappers for BlueGene
nodes: powerpc64-bgq-linux-gcc (BGQ-V1R2M2-150309) 4.4.7
fails attempting to build shared library (even with --disable-shared)
because only static libs are supported by the system:

./configure --disable-shared CC=/soft/compilers/wrappers/gcc/mpicc && make
&& make check
...
libtool: link: /soft/compilers/wrappers/gcc/mpicc -g -O2 -o gsl-randist
gsl-randist.o  ./.libs/libgsl.a cblas/.libs/libgslcblas.so -lm -Wl,-rpath
-Wl,/home/vale/tmp/gsl-tst/cross/gsl-2.3.90/cblas/.libs -Wl,-rpath
-Wl,/usr/local/lib
/bgsys/drivers/toolchain/V1R2M2_base-efix014/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld:
attempted static link of dynamic object `cblas/.libs/libgslcblas.so'
collect2: ld returned 1 exit status
make[2]: *** [gsl-randist] Error 1
make[2]: Leaving directory
`/gpfs/mira-home/vale/tmp/gsl-tst/cross/gsl-2.3.90'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/gpfs/mira-home/vale/tmp/gsl-tst/cross/gsl-2.3.90'
make: *** [all] Error 2



--
vale cofer-shabica
401.267.8253

On Wed, Jun 14, 2017 at 9:03 AM, Mohammad Akhlaghi <
mohammad.akhla...@univ-lyon1.fr> wrote:

> Hi Patrick,
>
> The `./configure', `make', and `make check' commands ran successfully on
> my system (Arch Linux, GCC 7.1.1, GNU C Library 2.25).
>
> To speed up the build, I usually run the Make commands with `-j8' to build
> in parallel on 8 threads on this system. `make -j8' worked nicely and
> everything was built. But when I ran `make check -j8', there was a
> segmentation fault for the `vector' tests (in P.S.). So I removed the `-j8'
> and all tests passed. This is probably due to dependencies in a
> multi-threaded check (where the tests are built at the same time, not after
> each other).
>
> So, I had a look at `vector/Makefile.am'. It shows that indeed no
> dependencies are defined for these tests. We had the same issue in
> Gnuastro's `make check' and was able to solve it using an intermediate
> script to run the built programs (and thus not including
> `$(check_PROGRAMS)' in `TESTS'.
>
> In the link below you can see Gnuastro's `tests/Makefile.am' (we have
> merged all the tests of all the programs/libraries into one Makefile). In
> particular, you can see the part under the "Library checks" title (line
> 194) and its comments.
>
> http://git.savannah.gnu.org/cgit/gnuastro.git/tree/tests/Makefile.am
>
> The `multithread.c' test program depends on the output of another test
> (`mkprof/mosaic1.sh'). So we have not put `$(check_PROGRAMS)' in `TESTS'
> and instead defined a small script (`lib/multithread.sh') which depends on
> the output of the dependent test (`mkprof/mosaic1.sh.log', line 207).
>
> Ofcourse, in the current architecture, GSL's tests are not unified in one
> `Makefile.am', but are distributed over separate files with a handful of
> (sometimes only one) test(s) in each. So running the tests in parallel will
> not significantly improve the speed. But to avoid confusion in cases like
> this, it can good to define dependencies like this so those tests that
> depend on others don't fail.
>
> Thank you very much,
> Mohammad
>
>
> P.S.
>
> make[2]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> make[3]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> ../test-driver: line 95: 32689 Segmentation fault  (core dumped) "$@"
> > $log_file 2>&1
> FAIL: test_static
> PASS: test
> make[4]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> make[4]: Nothing to be done for 'all'.
> make[4]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> 
> 
> Testsuite summary for gsl 2.3.90
> 
> 
> # TOTAL: 2
> # PASS:  1
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> 
> See vector/test-suite.log
> 
> 
> make[3]: *** [Makefile:741: test-suite.log] Error 1
> make[3]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make[2]: *** [Makefile:849: check-TESTS] Error 2
> make[2]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make[1]: *** [Makefile:927: check-am] Error 2
> make[1]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make: *** [Makefile:961: check-recursive] Error 1
>
>

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

[viktor drobot]

Hello!
./configure && make && make check
works fine on my system (Arch Linux, GCC 7.1.1, GLIBC 2.25)

However,
cd doc && make html
fails with the following error:
[viktor@freesky-lab ~/test/gsl-2.3.90/doc]$ LANG=C make html
Making html in .
make[1]: Entering directory '/home/viktor/test/gsl-2.3.90/doc'
make[1]: Nothing to be done for 'html-am'.
make[1]: Leaving directory '/home/viktor/test/gsl-2.3.90/doc'
Making html in examples
make[1]: Entering directory '/home/viktor/test/gsl-2.3.90/doc/examples'
make[1]: Nothing to be done for 'html'.
make[1]: Leaving directory '/home/viktor/test/gsl-2.3.90/doc/examples'
Error: Config directory doesn't contain a conf.py file.
make: *** [Makefile:835: html] Error 1


2017-06-14 17:19 GMT+03:00 Patrick Alken :

> Thanks Mohammad,
>
>   This is due to a file race condition I inadvertently introduced when
> trying to make those tests C89 compliant. I have uploaded a fix to the
> git, and will make a new test candidate release in a day or so, after
> getting more feedback.
>
>   I've sometimes wondered whether I should group all the GSL tests
> together into one Makefile, so that the summary output gives all the
> test statistics, rather than individual outputs for each module. I'm not
> sure which design is better, and haven't seen much information about
> this in the automake documentation.
>
> Patrick
>
> On 06/14/2017 03:03 PM, Mohammad Akhlaghi wrote:
> > Hi Patrick,
> >
> > The `./configure', `make', and `make check' commands ran successfully
> > on my system (Arch Linux, GCC 7.1.1, GNU C Library 2.25).
> >
> > To speed up the build, I usually run the Make commands with `-j8' to
> > build in parallel on 8 threads on this system. `make -j8' worked
> > nicely and everything was built. But when I ran `make check -j8',
> > there was a segmentation fault for the `vector' tests (in P.S.). So I
> > removed the `-j8' and all tests passed. This is probably due to
> > dependencies in a multi-threaded check (where the tests are built at
> > the same time, not after each other).
> >
> > So, I had a look at `vector/Makefile.am'. It shows that indeed no
> > dependencies are defined for these tests. We had the same issue in
> > Gnuastro's `make check' and was able to solve it using an intermediate
> > script to run the built programs (and thus not including
> > `$(check_PROGRAMS)' in `TESTS'.
> >
> > In the link below you can see Gnuastro's `tests/Makefile.am' (we have
> > merged all the tests of all the programs/libraries into one Makefile).
> > In particular, you can see the part under the "Library checks" title
> > (line 194) and its comments.
> >
> > http://git.savannah.gnu.org/cgit/gnuastro.git/tree/tests/Makefile.am
> >
> > The `multithread.c' test program depends on the output of another test
> > (`mkprof/mosaic1.sh'). So we have not put `$(check_PROGRAMS)' in
> > `TESTS' and instead defined a small script (`lib/multithread.sh')
> > which depends on the output of the dependent test
> > (`mkprof/mosaic1.sh.log', line 207).
> >
> > Ofcourse, in the current architecture, GSL's tests are not unified in
> > one `Makefile.am', but are distributed over separate files with a
> > handful of (sometimes only one) test(s) in each. So running the tests
> > in parallel will not significantly improve the speed. But to avoid
> > confusion in cases like this, it can good to define dependencies like
> > this so those tests that depend on others don't fail.
> >
> > Thank you very much,
> > Mohammad
> >
> >
> > P.S.
> >
> > make[2]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> > make[3]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> > ../test-driver: line 95: 32689 Segmentation fault  (core dumped)
> > "$@" > $log_file 2>&1
> > FAIL: test_static
> > PASS: test
> > make[4]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> > make[4]: Nothing to be done for 'all'.
> > make[4]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> > 
> 
> >
> > Testsuite summary for gsl 2.3.90
> > 
> 
> >
> > # TOTAL: 2
> > # PASS:  1
> > # SKIP:  0
> > # XFAIL: 0
> > # FAIL:  1
> > # XPASS: 0
> > # ERROR: 0
> > 
> 
> >
> > See vector/test-suite.log
> > 
> 
> >
> > make[3]: *** [Makefile:741: test-suite.log] Error 1
> > make[3]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> > make[2]: *** [Makefile:849: check-TESTS] Error 2
> > make[2]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> > make[1]: *** [Makefile:927: check-am] Error 2
> > make[1]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> > make: *** [Makefile:961: check-recursive] Error 1
> >
>
>
>


-- 
С уважением,
Дробот Виктор

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

[Patrick Alken]

Thanks Mohammad,

  This is due to a file race condition I inadvertently introduced when
trying to make those tests C89 compliant. I have uploaded a fix to the
git, and will make a new test candidate release in a day or so, after
getting more feedback.

  I've sometimes wondered whether I should group all the GSL tests
together into one Makefile, so that the summary output gives all the
test statistics, rather than individual outputs for each module. I'm not
sure which design is better, and haven't seen much information about
this in the automake documentation.

Patrick

On 06/14/2017 03:03 PM, Mohammad Akhlaghi wrote:
> Hi Patrick,
>
> The `./configure', `make', and `make check' commands ran successfully
> on my system (Arch Linux, GCC 7.1.1, GNU C Library 2.25).
>
> To speed up the build, I usually run the Make commands with `-j8' to
> build in parallel on 8 threads on this system. `make -j8' worked
> nicely and everything was built. But when I ran `make check -j8',
> there was a segmentation fault for the `vector' tests (in P.S.). So I
> removed the `-j8' and all tests passed. This is probably due to
> dependencies in a multi-threaded check (where the tests are built at
> the same time, not after each other).
>
> So, I had a look at `vector/Makefile.am'. It shows that indeed no
> dependencies are defined for these tests. We had the same issue in
> Gnuastro's `make check' and was able to solve it using an intermediate
> script to run the built programs (and thus not including
> `$(check_PROGRAMS)' in `TESTS'.
>
> In the link below you can see Gnuastro's `tests/Makefile.am' (we have
> merged all the tests of all the programs/libraries into one Makefile).
> In particular, you can see the part under the "Library checks" title
> (line 194) and its comments.
>
> http://git.savannah.gnu.org/cgit/gnuastro.git/tree/tests/Makefile.am
>
> The `multithread.c' test program depends on the output of another test
> (`mkprof/mosaic1.sh'). So we have not put `$(check_PROGRAMS)' in
> `TESTS' and instead defined a small script (`lib/multithread.sh')
> which depends on the output of the dependent test
> (`mkprof/mosaic1.sh.log', line 207).
>
> Ofcourse, in the current architecture, GSL's tests are not unified in
> one `Makefile.am', but are distributed over separate files with a
> handful of (sometimes only one) test(s) in each. So running the tests
> in parallel will not significantly improve the speed. But to avoid
> confusion in cases like this, it can good to define dependencies like
> this so those tests that depend on others don't fail.
>
> Thank you very much,
> Mohammad
>
>
> P.S.
>
> make[2]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> make[3]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> ../test-driver: line 95: 32689 Segmentation fault  (core dumped)
> "$@" > $log_file 2>&1
> FAIL: test_static
> PASS: test
> make[4]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
> make[4]: Nothing to be done for 'all'.
> make[4]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> 
>
> Testsuite summary for gsl 2.3.90
> 
>
> # TOTAL: 2
> # PASS:  1
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
>
> See vector/test-suite.log
> 
>
> make[3]: *** [Makefile:741: test-suite.log] Error 1
> make[3]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make[2]: *** [Makefile:849: check-TESTS] Error 2
> make[2]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make[1]: *** [Makefile:927: check-am] Error 2
> make[1]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
> make: *** [Makefile:961: check-recursive] Error 1
>

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

[Mohammad Akhlaghi]

Hi Patrick,

The `./configure', `make', and `make check' commands ran successfully on 
my system (Arch Linux, GCC 7.1.1, GNU C Library 2.25).


To speed up the build, I usually run the Make commands with `-j8' to 
build in parallel on 8 threads on this system. `make -j8' worked nicely 
and everything was built. But when I ran `make check -j8', there was a 
segmentation fault for the `vector' tests (in P.S.). So I removed the 
`-j8' and all tests passed. This is probably due to dependencies in a 
multi-threaded check (where the tests are built at the same time, not 
after each other).


So, I had a look at `vector/Makefile.am'. It shows that indeed no 
dependencies are defined for these tests. We had the same issue in 
Gnuastro's `make check' and was able to solve it using an intermediate 
script to run the built programs (and thus not including 
`$(check_PROGRAMS)' in `TESTS'.


In the link below you can see Gnuastro's `tests/Makefile.am' (we have 
merged all the tests of all the programs/libraries into one Makefile). 
In particular, you can see the part under the "Library checks" title 
(line 194) and its comments.


http://git.savannah.gnu.org/cgit/gnuastro.git/tree/tests/Makefile.am

The `multithread.c' test program depends on the output of another test 
(`mkprof/mosaic1.sh'). So we have not put `$(check_PROGRAMS)' in `TESTS' 
and instead defined a small script (`lib/multithread.sh') which depends 
on the output of the dependent test (`mkprof/mosaic1.sh.log', line 207).


Ofcourse, in the current architecture, GSL's tests are not unified in 
one `Makefile.am', but are distributed over separate files with a 
handful of (sometimes only one) test(s) in each. So running the tests in 
parallel will not significantly improve the speed. But to avoid 
confusion in cases like this, it can good to define dependencies like 
this so those tests that depend on others don't fail.


Thank you very much,
Mohammad


P.S.

make[2]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
make[3]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
../test-driver: line 95: 32689 Segmentation fault  (core dumped) 
"$@" > $log_file 2>&1

FAIL: test_static
PASS: test
make[4]: Entering directory '/home/id/desktop/gsl-2.3.90/vector'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'

Testsuite summary for gsl 2.3.90

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See vector/test-suite.log

make[3]: *** [Makefile:741: test-suite.log] Error 1
make[3]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
make[2]: *** [Makefile:849: check-TESTS] Error 2
make[2]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
make[1]: *** [Makefile:927: check-am] Error 2
make[1]: Leaving directory '/home/id/desktop/gsl-2.3.90/vector'
make: *** [Makefile:961: check-recursive] Error 1

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

[Patrick Alken]

On 06/14/2017 02:14 PM, Arun Isaac wrote:
>> ./configure && make && make check
> ./configure fails with
>
> config.status: error: cannot find input file: `bspline/Makefile.in'
>
> Am I missing something?
>
That file bspline/Makefile.in should be included in the package

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

[Arun Isaac]

> ./configure && make && make check

./configure fails with

config.status: error: cannot find input file: `bspline/Makefile.in'

Am I missing something?