FPE_SS(3)FPE_SS(3)


NAME
     fpe_trace_option - SpeedShop Floating-Point Exception (FPE) tracing
     library

SYNOPSIS
     void fpe_trace_option(int trap_type, struct sigcontext *sc);

IMPLEMENTATION
     IRIX systems

DESCRIPTION
     The SpeedShop Performance Tools contain a floating-point exception
     tracing library, libfpe_ss.so, which provides tracing for
     floating-point exceptions.

     NOTE:  users do not call this routine, rather it is invoked from the
     standard FPE library.

     The library provides an intercept layer for the call to
     fpe_trace_option, generated by the standard FPE library.  It allows
     tracing of all FPEs with the SpeedShop performance tools.  It is
     normally not linked or invoked directly; the ssrun(1) command uses
     rld(1) to ensure that the library is in the process's address space
     when an FPE tracing experiment is run.

TRACED EXCEPTIONS
     There are four distinct types of floating-point exceptions:
     underflow, overflow, divide-by-zero, and invalid operation.  There is
     a fifth exception that is traced in the same way:  integer overflow.
     The summary on this man page is only approximate.  For further
     details, see the instruction set description for the particular CPU
     chip involved.  The description on this man(1) page is only for cases
     in which a SpeedShop FPE tracing experiment is being performed and no
     special settings for exceptions have been used.

     Underflows are generated when an arithmetic operation would produce a
     result that is too small to be represented as a normalized
     floating-point number.  Each time such a result is generated, an
     exception occurs, and it is traced.  If the operation generates a
     result that can not even be represented as an denormalized floating-
     point number, a zero is generated.  Further use of this zero will
     never produce another underflow.

     Overflows are generated when an arithmetic operation would produce a
     result that is too large to be represented as a normalized
     floating-point number.  Each time this happens, an exception is
     generated, and the result is set to a (signed) infinity.  When such an
     infinity is subsequently used, it will propagate, but no exception is
     generated.  For some setting of the rounding mode, an infinity is not
     generated; rather, the largest representable value is generated.

     Divide-by-zero is generated when any finite nonzero number is divided
     by a zero.  It, too, generates an exception, and the result is also
     set to the representation of infinity (properly signed).  Subsequent
     use will not cause another exception.

     Invalid operations occur when a zero is divided by a zero.  They
     generate an exception, and the result is set to a special result
     called Not a Number, or NaN.  Although the IEEE specification allows
     for both signaling NaNs and nonsignaling NaNs, the hardware only
     generates nonsignaling NaNs, and subsequent use of this result will
     not generate another exception.  The same exception can occur when
     dividing two infinities, multiplying an infinity by a zero, adding a
     positive and a negative infinity, subtracting two infinities of the
     same sign, taking the square root of a negative number, converting
     between floating and fixed point, and comparing NaNs.

     The integer arithmetic instructions add, addi, dadd, daddi, sub, and
     dsub generate a SIGFPE signal when the result of the operation
     overflows.

     NOTE:  SGI compilers generate only unsigned versions of these
     instructions, which do not generate a signal on overflow.  However it
     is still possible to generate these instructions via assembly
     language.  Unless you have linked in some hand-coded assembly code,
     you will not see the integer-overflow exception.

DIAGNOSTICS
     As output from the library routines.

SEE ALSO
     prof(1), rld(1), speedshop(1), ssdump(1), ssrun(1).

     fsigfpe(3F), sigfpe(3C).