[J3] Question on overflow and run-time detection of infinity?

[Clune, Thomas L. (GSFC-6101)]

On Nov 27, 2018, at 10:14 AM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

On Tue, Nov 27, 2018 at 8:52 AM Clune, Thomas L. (GSFC-6101) via J3
<j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

Thanks Malcolm.

I will indeed try to get things fixed in gfortran.      I wanted to make certain I was not being unreasonable before pushing the issue further.

If the patch is trivial, I may attempt it myself, otherwise it will be  a bug report. ..


Tom,

As indicated by Steve Kargl earlier, it makes sense *not* to employ
any processor-specific compilation options such as -ffpe-trap=xxx if
you are looking to employ IEEE-related facilities in the language, for
the standard doesn't seem to prohibit (at least based on the verbiage
I skimmed through in 18-007r1) a processor from overriding the
behavior expected of methods in IEEE modules.

Well …  we really like to use flags such as this one for the very large weather model we maintain/develop.    Overflows in the numerical model almost always indicate a problem that needs attention, and retrofitting all of them with the IEEE facilities is not a high priority.    But my new layer could probably be properly instrumented with IEEE and then compiled without the offending flag.   The painful bit is a bit silly.    CMake is good at adding flags in subdirectories, but not in deleting them.  Currently the model “adds” the overflow flag at a high level, and that would need to be propagated to the lower levels.  Not terribly difficult, just not “fun”.

 IEEE facilities in the
language standard appear comprehensive enough to give you reasonable
control over floating-point exceptions i.e., when to turn on the
halting modes and when not to that one can do away with most, if not
all, of the compile-time processor-specific options.

Notwithstanding above comment, you may want to check with GCC
volunteers on the following, unless you know the answer already:

1) why does a return value of IEEE_POSITIVE_INF from the IEEE_VALUE
function turn on the IEEE_INEXACT flag with gfortran-compiled code?

2) why does the compiler option for overflow floating-point exception
as in -ffpe-trap=overflow turn on the trap with SIGFPE for inexact
signal and lead to a program abort?  That is, what does the overflow
trap have to do with inexact flag?


Are you sure that “inexact” is relevant?     I was assuming that I am seeing IEEE_OVERFLOW.   The actual message is more generic:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Cheers,

- Tom


Thanks,
Vipul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20181127/999fde82/attachment-0001.html>