fpe_trace_option, fpe_ss, fpe - SpeedShop floating-point exception
void fpe_trace_option(int trap_Type, struct sigcontext *sc);
The SpeedShop Performance Tools contain a floating-point exception
tracing library, -lfpe_ss, which provides tracing for floating-point
The library provides an intercept layer for the call to fpe_trace_option,
generated by the standard fpe library. Note that users do not call this
routine, rather it is invoked from the standard FPE library. It allows
tracing of all FPE's with the SpeedShop performance tools. It is
normally not linked or invoked directly; the ssrun(1) command will use
rld to ensure that the library is in the process' address space when an
fpe tracing experiment is run.
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
below is only approximate. For further details, see the instruction set
description for the particular CPU chip involved. The description below
is only for those cases when a SpeedShop floating point exception 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
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 non-zero number is divided by
a zero. It too generates an exception, and the result is also set to the
representation of infinity (properly signed), and subsequent use will not
cause another exception.
Invalid operations occur when a zero is divided by a zero. They
generates 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 NaN's and non-signaling NaN's, the hardware only generates
non-signaling NaN's and the 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, or adding a positive
and a negative infinity, subtracting two infinities of the same sign,
taking the square root of a negative number, during some conversions
between floating- and fixed-point, and during some comparisons of NaN's.
The integer arithmetic instructions add, addi, dadd, daddi, sub, and dsub
also generate a SIGFPE signal when the result of the operation overflows.
(At the moment, 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 assembler, you will not see the
handle_sigfpes(3C), ssrun(1), prof(1), ssdump(1), speedshop(1).
As output from the library routines.
PPPPaaaaggggeeee 2222 [ Back ]