dmon
dmon

Reputation: 1422

Fortran Arithmetic Exception

This is a short question but I have tried to give as much detail as possible.

I am compiling an old, but still actively developed, fortran code (f77 standard) on Scientific Linux. The recommended compilers for this code are ifort and gfortran. Using gfortran I can compile and run this code. However, if I make with the DEBUG=1 flag the code compiles but terminates with a SEG FAULT. Stepping through with gdb leads to the following source of error:

REAL*4 TIME_CURRENT     
CALL CPU_TIME(TIME_CURRENT) 
ISECS = 100*INT(TIME_CURRENT)  

The program terminates with:

Program received signal SIGFPE, Arithmetic exception. 
timer (init=1, isecs=0) at myprog.f:1818
1818 ISECS = 100*INT(TIME_CURRENT)

If I stop execution on line 1818 and examine ISECS and TIME_CURRENT I get:

(gdb) ptype(TIME_CURRENT)
type = real(kind=4)
(gdb) ptype(ISECS)
type = integer(kind=4)

I've tried being more specific and using:

ISECS = 100*INT(TIME_CURRENT,4)

But it doesn't help. I fail to see how this could equate to an Arithmetic error?

My (makefile generated) debug compile flags are:

gfortran -fno-automatic -m32 -O0 -g \
         -ffpe-trap=invalid,zero,overflow,underflow,precision -static-libgfortran

When I compile out of debug I no longer receive a SEG FAULT but and my compile flags are

gfortran -fno-automatic -m32 -O2 -ffast-math -static-libgfortran

I am not a fortran programmer so any assistance would be greatly appreciated. Please note, I am compiling on a 64bit system but forcing a 32bit compilation, as this is required.

Upvotes: 2

Views: 2578

Answers (1)

Your code does not look like FORTRAN 77, CPU_TIME is from Fortran 95. Anyway, your options for the debug are extremely strict. -ffpe-trap=invalid,zero,overflow,underflow,precision means many legitimate uses of floating point arithmetic will cause an exception. I recommend to use just -ffpe-trap=invalid,zero,overflow.

Specifically from gfortran manual:

Some of the routines in the Fortran runtime library, like CPU_TIME ,
are likely to trigger floating point exceptions when "ffpe-trap=precision"
is used. For this reason, the use of "ffpe-trap=precision" is not recommended.

Upvotes: 9

Related Questions