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
