0

I am trying to debug a Fortran program. To catch floating point errors, I'm using the following compiler options for gfortran 4.9.0:

FFLAGS1 = -std=f2003 -ffree-form -fdefault-real-8 -fdefault-double-8  \
          -Ofast -fall-intrinsics -fcheck=all -m64 \
          -fno-trapping-math -c \
          -ffpe-trap=invalid,zero,overflow,underflow,precision,denormal -Wall

With these options, the program fails at this line:

read(ctrlUnit,*) slope_fasst, aspect

when trying to read these inputs: 10.0 70.0

If I remove

-ffpe-trap=invalid,zero,overflow,underflow,precision,denormal

from the compiler options, it reads the following line just fine. Both variables are declared as real(8). In the input file, I've tried spaces, commas, etc. but see no changes. Does anyone have a suggestion?

francescalus
  • 30,576
  • 16
  • 61
  • 96
user2417662
  • 47
  • 1
  • 4
  • 2
    What error does the run-time system report ? And what is the program trying to read when it fails ? – High Performance Mark Apr 03 '15 at 13:56
  • I'm trying to read these inputs: 10.0 70.0 – user2417662 Apr 03 '15 at 17:20
  • Are those the only inputs that are being read? That's somewhat interesting, in that `10.0` and `70.0` *are* exactly representable in either single- or double-precision IEEE 754 floating-point, so it must be errors that occur *during* the conversion process that trigger the trap. Ideally, the conversion from string would only set the inexact flag if the final result is not exactly representable. – Mark Dickinson Apr 03 '15 at 18:36
  • If @user2417662 comes back maybe he can tell us the compiler version. – agentp Apr 03 '15 at 20:25
  • Yes, those are the only numbers being read in. The compiler version is gfortran 4.9.0. – user2417662 Apr 04 '15 at 01:44

1 Answers1

1

It seems the gfortran -ffpe-trap,precision flag results in errors for perfectly normal / routine read/write operations.

For example, this program throws a "Floating exception" error:

    write(*,*)1.0
    end

(gfortran 4.1.2, redhat linux)

Solution, do not use that flag.

Note this makes sense since the conversion from machine number to/from ascii results in a loss of precision ( I'm not sure if thats the intent of the flag to catch such though )

agentp
  • 6,849
  • 2
  • 19
  • 37
  • 1
    Yes, `precision` sounds like it must correspond to the usual IEEE 754 "Inexact" trap. Since many many floating-point operations can give inexact results, including conversion from string, I'd imagine that a typical program using floating-point would be unusable with that flag set. – Mark Dickinson Apr 03 '15 at 18:31
  • gfortran 4.1.2 is from 2007. It is a very old version, early in the development of gfortran. My opinion: don't use any version before 4.4. – M. S. B. Apr 03 '15 at 20:10
  • @MarkDickinson: Indeed "precision" corresponds to the IEEE 754 inexact exception. This was fixed in 2011, nowadays gfortran instead uses "inexact", (while keeping "precision" as an alias for backwards compatibility). – janneb Apr 03 '15 at 21:38
  • I took out precision and it made no difference. – user2417662 Apr 04 '15 at 01:48
  • 1
    try removing the flags one at a time to see what the cause is. ( And posting the exact error message might be useful ) – agentp Apr 04 '15 at 14:03