https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Matt Thompson from comment #0)
> All,
>
> A colleague of mine encountered an issue with 8.2.0 (but it's also in 7.3.0
> at least). We believe it might be a bug since our reading of the Standard
> seems to make it legal.
>
> Namely if this program:
>
> PROGRAM test
> USE, INTRINSIC :: ieee_arithmetic
> IMPLICIT NONE
> REAL :: inf
> inf = IEEE_VALUE(inf, IEEE_POSITIVE_INF)
> END PROGRAM test
>
> is compiled with -ffpe-trap=overflow the code FPEs:
gfortran's IEEE modules and the -ffpe-trap option are independent
of each other. As the manual states, -ffpe-trap is a *debugging*
option, and will enabling traps on floating point exceptions. You
specifically requested an overflow trap. What do you expect to
happen?
The likely correct solution is to manipulate the halting
behavior with a combination of IEEE_GET_HALTING_MODE and
IEEE_SET_HALTING_MODE. In fact, F2018, 17.11.6 contains
this exact example.
Example. To store the halting mode for IEEE_OVERFLOW, do a
calculation without halting, and restore the halting mode later:
USE, INTRINSIC :: IEEE_ARITHMETIC
LOGICAL HALTING
...
CALL IEEE_GET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Store halting mode
CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, .FALSE.) ! No halting
... ! calculation without halting
CALL IEEE_SET_HALTING_MODE (IEEE_OVERFLOW, HALTING) ! Restore halting mode
whether or not these functions works is something that I
haven't investigated.
