[comp.lang.fortran] IEEE exceptions

macq@miguel.llnl.gov (Don MacQueen) (02/26/91)

This is basic stuff, I suppose, and I've looked in the documentation I have available, but I need some help evaluating the following runtime message from my code.  The code involves numerical integration of a normal distribution function.

Warning: the following IEEE floating-point arithmetic exceptions
occurred in this program and were never cleared:
Inexact; Underflow;

This is on a Sun Sparcstation IPC using f77, with or without the -r8 option.

I know why the underflow is occuring, and I have no problem with underflow as long as zero is used in subsequent calculations.

Can I assume that 'Inexact' is occurring for the same reason that underflow is occurring?  What exactly (or inexactly?) does inexact mean?  What does it mean to 'clear an exception'?

Thanks
-- 
--------------------
Don MacQueen
macq@miguel.llnl.gov
--------------------

mcdowell@xanth.msfc.nasa.gov (Jonathan McDowell) (02/26/91)

macq@miguel.llnl.gov (Don MacQueen) writes:
[ Gets an error message due to IEEE exceptions in Sun fortran, integrating
a normal distribution].

Sun fortran lets you divide by zero and other fun things during your program
and only lets you know at the end. I actually find this quite useful as I use
the NaN (Not a Number) value (obtained by y=0./0.) as a null value for missing
data, to avoid the nastiness of using -999.9 etc. But not letting you know until

the end of the program is silly.

 I generated Don's error with the following simple program:

xanth{mcdowell}[59]t% cat test.f
        y=exp(-400.0)
        write (*,*) y
        end             
xanth{mcdowell}[60]t% a.out
  0.
 Warning: the following IEEE floating-point arithmetic exceptions 
 occurred in this program and were never cleared: 
 Inexact;  Underflow; 

>Can I assume that 'Inexact' is occurring for the same reason that underflow is 
occurring?  
>What exactly (or inexactly?) does inexact mean? 
 It would appear so; I guess that inexact means 'some exception that loses preci
sion' 
(as opposed to 'Invalid Operand' which you get when you replace the exp above wi
th a
sqrt) and is followed by the name of the specific exception that has occurred. 

>What does it mean to 'clear an exception?'

 I remove the annoying error message from the above program with
xanth{mcdowell}[66]t% cat test.f
        y=exp(-400.0)
        write (*,*) y
        call sys_exit
        END
c-------------------------------------------
       subroutine sys_exit
c Avoid nasty error message on exit
       integer ierr,ieee_flags
       character out*16
       ierr=ieee_flags ('clear','exception','all',out)
       end
                        
xanth{mcdowell}[67]t% a.out
 0.
                                                                          
Of course, this also stops any 'Invalid Operand' warnings that
you may incur.


 .-----------------------------------------------------------------------------.

 |  Jonathan McDowell                 |  phone : (205)544-????                 |

 |  Space Science Lab ES65            | uucp:                                  |

 |  NASA Marshall Space Flight Center | bitnet :                               |

 |  Huntsville AL 35812               |  inter : mcdowell@xanth.msfc.nasa.gov  |

 |  USA                               |   span : ssl::mcdowell                 |

 '-----------------------------------------------------------------------------'

carlo@oddjob.uchicago.edu (Carlo Graziani) (02/28/91)

In article <mcdowell.667579808@xanth> mcdowell@xanth.msfc.nasa.gov (Jonathan McDowell) writes:
>Sun fortran lets you divide by zero and other fun things during your program
>and only lets you know at the end. I actually find this quite useful as I use
>the NaN (Not a Number) value (obtained by y=0./0.) as a null value for missing
>data, to avoid the nastiness of using -999.9 etc. But not letting you know until
>
>the end of the program is silly.

Hi.  The following method is the one to which I have had to resort in
order to track down floating point exceptions on a Sun Sparcstation.
It's a bit of a kludge, but at least it allows identification of the
routine within which the exception occurred, and the problem can
usually be identified using dbx:

      program foobawooba

      external handler

      common /debug1/nlevel
      common /debug2/ stack(20)
      character stack*25
      data nlevel/1/stack/'main',19*''/

      ieeer=ieee_handler('set','common',handler)

c 'common' handles invalid, overflow, and division exceptions --- see
c "man ieee_handler".  handler is an external routine shown at the end
c of this example.  This line will call handler whenever a 'common'
c exception occurs.

      .
      .
      .
      call haha1
      .
      .
      .
      stop
      end

      subroutine haha1
      common /debug1/nlevel
      common /debug2/ stack(20)
      character stack*25
      nlevel=nlevel+1
      stack(nlevel)='haha1'
      .
      .
      .
      call haha2
      .
      .
      .
      stack(nlevel)=''
      nlevel=nlevel-1
      return
      end

      subroutine haha2
      common /debug1/nlevel
      common /debug2/ stack(20)
      character stack*25
      nlevel=nlevel+1
      stack(nlevel)='haha2'
      .
      .
      .
      stack(nlevel)=''
      nlevel=nlevel-1
      return
      end

      integer function handler ( sig, code, sigcontext )
      common /debug1/nlevel
      common /debug2/ stack(20)
      character stack*25
      integer sig
      integer code
      integer sigcontext(5)

      write(6,*) 'Bomb!  Here comes a stack dump:'
      do 1 i=1,nlevel
        write(6,*) stack(i)
1     continue
      write(6,*) 'Number of levels:',nlevel
      call abort
      end

The effect of all these (admittedly ugly and machine specific)
gymnastics is that the routine in which the exception occurred is
pinpointed by the array 'stack' and the variable 'nlevel'.  Since
execution is halted by means of 'call abort', all the debugging
information is still available, and the problem may be identified (if
the debugger was active) by examining the guilty routine.  The ass
paining part of all this is that the lines affecting 'stack' and
'nlevel' must be included at the beginning of every routine in the
program, as well as before every return statement.  I'm not that happy
with it, but it's the best I've been able to do.  One might wish that
it would dawn on  the *%&#!@!? C programmers who developed Fortran for
the Sun that for the purposes of scientific programming, failure to
*automatically* halt on division by zero is a bug, not a feature :-(> .


Carlo Graziani.

khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/28/91)

In article <1991Feb27.205044.18345@midway.uchicago.edu> carlo@oddjob.uchicago.edu (Carlo Graziani) writes:

   It's a bit of a kludge, but at least it allows identification of the
   routine within which the exception occurred, and the problem can
   usually be identified using dbx:

why not just do as the documentation suggests:


	 ieeer=ieee_handler('set','common',SIGFPE_ABORT) ! aka %val(2), see
							 ! Fortran Users Guide
							 ! f77_floatingpoint.h, etc.

the traceback (v1.3) and/or dbx where then shows the location of the
event. If you compiled -g you get the exact line number.


   it would dawn on  the *%&#!@!? C programmers who developed Fortran for
   the Sun that for the purposes of scientific programming, failure to
   *automatically* halt on division by zero is a bug, not a feature :-(> .

compiling -fnonstnd has that effect. Due to a minor bug in v1.3 one
can't completely rely on it; but it is robust in v1.4.

IEEE 754 had a fair amount of Fortran influence.X3J3, the fortran
committee has never made any statement about the "correct" behavior of
/0 etc. .... by choice.

As it happens, I am a Fortran programmer (I still run and write more
of it than C) and I don't want the machine to necessarily halt. I've
made a fair number of codes run faster because I was able to defer
checking until after the critical computations ....

Since there clearly are folks who do want the system to halt, we made
it a 1-line change to the code, if you want non-ieee compliant
behavior .... and eventually even a compiler option. Hopefully that
comes close enough to what you desire....

cheers
--
----------------------------------------------------------------
Keith H. Bierman    kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043