On 2015-05-12 09:41-0400 Hazen Babcock wrote: >> >> On 05/11/2015 06:05 PM, Alan W. Irwin wrote: >>> >>> Hi Hazen: >>> >>> I am glad to hear you have created a topic branch that catches >>> floating point exceptions. However, I am not keen on pulling a PLplot >>> topic branch from github for the reasons discussed in >>> README.developers. So could you either share your topic branch using >>> "git format-patch" or else just push it to our official repo yourself? >>> The former is preferred if the work is incomplete (i.e., does not >>> include a cmake option to control when the PLPLOT_ENABLE_FLOAT_EXCEPT >>> macro is #defined). Furthermore, if the work is incomplete, I can >>> finish the cmake aspects of it as promised above and amend your commit >>> accordingly. >>> >>> Once we have implemented an option to check for floating-point >>> exceptions, then that means any of us should be able to confirm the >>> ones you have found and find others in the future due to the continued >>> evolution of our examples. And, of course, this option should allow >>> us to fix those floating-point exceptions as time permits. >> >> Hi Alan, >> >> Sorry, that branch was not meant for incorporation into PLplot which is >> why I did not follow accepted protocols. I thought it might make it >> easier for others to see the floating point exception problem for these >> 3 examples. >> >> I think we can enable floating point exception trapping more easily >> using the -ffpe-trap option provided by gfortran. This won't require us >> to mark up all of our C examples, though we might instead need to check >> that the fortran compiler is gfortran? >> >> https://gcc.gnu.org/onlinedocs/gfortran/Debugging-Options.html >> >> -ffpe-trap=invalid,zero,overflow,underflow >> >> Compiling PLplot with this fortran flag (CMAKE_Fortran_FLAGS) "worked" >> for me in that it core dumps on the fortran equivalents of the C >> examples I mentioned above. I've attached my CMakeCache.txt file. >> >> -Hazen > > Hm.. example 21 also generates an FPE, but at least in this case it > looks like it is coming from the qhull library. And example 29 also > generates an FPE, but only the Fortran version not the C version. So, > maybe it would be better in the end to add this check to all of the C > examples as well?
I sympathize with your desire not to mark up all the examples. Which lead to the thought that if gfortran has an option to report the above exceptions without additional code markup, then gcc might have such options as well. A google search on the terms <gcc floating point exception traps> found somehow else had asked that exact question at <http://stackoverflow.com/questions/18644168/catch-floating-point-exceptions-using-a-compiler-option-with-c> I don't understand the answers myself, but perhaps they might be useful to you. If it turns out the answer is currently "no" (i.e., you must mark up the examples in order to detect floating-point exceptions with gcc), then I think we could probably just stick with gfortran and -ffpe-trap=invalid,zero,overflow,underflow. Of course, the fortran examples go through a lot of additional code before finally calling our core C library so this method should detect floating-point exceptions in the fortran example implementation, the fortran wrapper library code, AND, our core C library. So we do want to solve all of those. Furthermore, once we have done so then I believe the only C floating-point exception left that would go undetected would be in the actual C example implementation, i.e., if we divided by 0. right in one of the examples. But we guard against such issues in other ways (with the comparisons of PostScript and SVG results) so I don't think we need to be concerned about such an issue. If you agree with my above reasoning that gfortran with -ffpe-trap=invalid,zero,overflow,underflow is what we want to do going forward to detect floating point exceptions, then I hope you have the time to fix all the causes of those exceptions in this release cycle. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
