Ethan Merritt

Confirmed. It broke between 6.0.1 and 6.0.2 . The breakage was imported from 6.1 so the fix is needed there also. Fix pushed for both branch-6-0-stable and master

I am puzzled. Your minimal reproducer is a real bug (trying to plot from an empty data block). I pushed a fix to both 6.0 and 6.1 But that pattern does not occur in mask_pm3d.dem. I cannot reproduce failure with that demo either before or after the fix. Edit: OK, I see that the problem could occur with that demo if the loadpath, or GNUPLOT_LIB, is set incorrectly. Then it would try to create a data block from a file not in the search path, resulting in an empty data block.

I am puzzled. Your minimal reproducer is a real bug (trying to plot from an empty data block). I pushed a fix to both 6.0 and 6.1 But that pattern does not occur in mask_pm3d.dem. I cannot reproduce failure with that demo either before or after the fix.

Looks good. The only other thing I see is that when you add a file to the package, it needs to be listed in .../src/Makefile.am gnuplot_SOURCES so that the automake system tracks it and includes it in the source package from "make dist". diff --git a/src/Makefile.am b/src/Makefile.am index 8e0685733..132111689 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -56,7 +56,7 @@ help.c help.h hidden3d.c hidden3d.h history.c internal.c internal.h \ interpol.c interpol.h jitter.c jitter.h libcerf.c...

Applied. Thanks.

Ugh. I am extremely embarrassed that I missed this pitfall when I first added support for 64 bit integers. Everywhere that this code pattern appears is potentially susceptible to errors due to loss of precision: (double)(<FOO>.v.int_val) This pitfall is intrinsic to the IEEE floating point representation, so it is relevant not just for recent clang or gcc compiler options. In some places the loss of precision affects possible overflow; in others it does not. So I am now thinking we need the full...

Ugh. I am extremely embarrassed that I missed this pitfall when I first added support for 64 bit integers. Everywhere that this code pattern appears is potentially susceptible to errors due to loss of precision: (double)(<FOO>.v.int_val) This pitfall is intrinsic to the IEEE floating point representation, so it is relevant not just for recent clang or gcc compiler options. In some places the loss of precision affects possible overflow; in others it does not. So I am now thinking we need the full...

Here's a matching addition to fix f_prod(). This one is needed for current gcc, even aside from the issue of clang compiler options. Example of failure before N = 2**21 - 1 prod [i=1:3] N = 9223358842721533951 N*N*N = 9223358842721533951 prod [i=1:4] N = 26388270678017 N*N*N*N = 1.93427762203723e+25 After the fix prod [i=1:4] N = 1.93427762203723e+25 N*N*N*N = 1.93427762203723e+25 I did not find any other affected routines, but I suppose there could be some. The core code does not make much use of...