We are using gfortran (5.3.1), Fedora 23, in a new 64 b machine. Compiling with simple gfortran -o (we are not using -ffpe-trap options !), excites the "classical- trivial" warning:
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG
Its due to INEXACT exception (type 2.0/3.0). The DDD debugger points towards a real constant (180d0/pi; pi = 3.141518...). We don't understand why this flag appears, with this basic compilation, because these exceptions are reached all the time...
Some code here:
Implicit none !real*8(a-h,o-z)
real*8 pi,dpi,radgra,TSI,TOL,xlsol,fi,W
Integer year, T1, k,m
open(10,file='stof-elem.sol')
pi = 4.d0 * datan(1.d0)
dpi = 2.d0 * pi
radgra = 360.d0 / dpi !!!!!!!! HERE POINTS THE EXCEPTION!!!!!!!!!!
T1 = -9998 !800d0 !1450d0 !
TSI = 1360.d0 !1364.5d0 !1367d0
TOL = 0.7d0 / radgra ! dont' use smaller
C...Name of the output file
open(12,file='midmonth-2000.sal')
C-----------------------------------------------------------------------
k = 0 ! outputs counter
write(12,*)T1
DO m = 1, 12 ! select month
IF(T1.lt.0) then
xlsol = (270.d0 - dble(m-1) * 30.d0) / radgra !from Dec
if(xlsol.lt.0d0) xlsol = xlsol + dpi
ELSE
xlsol = dble(m-3) * 30.d0 / radgra !from Jan
if(xlsol.lt.0d0) xlsol = xlsol + dpi
ENDIF
CALL MEANINSOLA(pi,dpi,radgra,TOL,T1,TSI,xlsol,fi,k,W)
rewind(10) ! better rewind...
ENDDO
write(*,*) 'Outputs:', k,'lines'
The EXCEPTION appears at the definition of RADGRA ... as indicated. If redefine the constant (i.e.,, RADGRA = 57.2d0), the exception migrates to another parts using RADGRA... and so on...