On 2015-05-13 11:29-0400 Hazen Babcock wrote: > On 05/12/2015 01:22 PM, Alan W. Irwin wrote: >> [...]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. > > I'd add it to the debug build flags for fortran. Perhaps a check is also > needed that the fortran compiler is gfortran?
Hi Hazen: Actually, we don't have to (and should not) change anything in our code base. Instead, the tester should simply set an environment variable to choose the compiler and its options. For example, you should be able to use export FC='/usr/bin/gfortran -g -ffpe-trap=invalid,zero,overflow,underflow' before running cmake (where the -g option sets up using gdb on the results). In my case the only fortran compiler available is gfortran so I don't need to choose that. So instead of the above I set export FFLAGS='-g -ffpe-trap=invalid,zero,overflow,underflow' before calling cmake and building the x29f95 and ps targets. After that, I got the following result software@raven> examples/f95/x29f -dev psc -o test.psc Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. [...] So I confirm there is a floating-point issue for that example, and this should be easy for anyone else here to confirm that has access to gfortran. However, I am completely tied up with other PLplot issues so I would appreciate it if you pursued and fixed all floating-point issues revealed by this method. But if you are too busy to do that yourself, please let this list know so others with more time will be motivated to take a crack at it. 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
