IEEE exceptions and compilers

[David G. Hough at validgh]

If you're not interested in compiler product issues, don't bother reading
this...

Within Sun there has been an ongoing discussion of a number of features of its
Fortran compilers.    
Since the issues are applicable to most of us on numeric-interest
in one way or another, I'd 
be interested in knowing what the users of floating-point programs, on one
hand, and compiler vendors, on the other, think of the following issues.

I.  Default behavior

Since 1988, Sun Fortran by default has had these features:

1) Nonstop exception handling.   By default, execution continues past all
numeric exceptions, in accordance with section 7 of IEEE 754.   IEEE 754
requires nonstop exception handling because there is no feasible way to
design portable efficient algorithms that can successfully avoid hazards
of abrupt termination.

All Sun compilers behave the same way.  It is 
possible to alter this behavior with ieee_handler(3f or 3m) or with the
command-line option -fnonstd.

2) Gradual underflow.   By default, in accordance with IEEE 754, underflow
may produce subnormal results, and subnormal operands are interpreted as
nonzero.    This may entail a performance penalty on some systems such
as older SPARCs and HyperSPARC, but not on MicroSPARC or SuperSPARC.
Hardware that exhibits that performance penalty provides a nonstandard
mode which treats subnormal results and operands as zero and is thereby
faster.    That behavior may be enabled by the command-line option -fnonstd
or by invoking nonstandard_arithmetic(3m).

3) Retrospective diagnostics.   By default, at the normal or abnormal end
of execution of a Fortran program, a message is sent to stderr if
any of the following are true:

	any accrued IEEE exception bits on besides inexact
	any IEEE traps enabled
	nonstandard arithmetic enabled

Except that if the only true condition among these were that the accrued
inexact bit were on, then the message is suppressed on the grounds
that an inexact floating-point calculation was not newsworthy. 
For some releases the retrospective also reported whether infinities or NaNs
occurred in decimal input or output, but that required coordination between
printf/scanf in libc and the math library, which became untenable in later
releases.

Only Fortran and Pascal provided this retrospective feature, because they were
implemented on top of C's infrastructure.    The retrospective message
could always be suppressed if desired
by clearing the indicated conditions prior to
termination, and in all but one release by adding a dummy function

	subroutine ieee_retrospective
	return
	end

to the source code.

The purpose of the retrospective message is to indicate that some unusual
conditions arose which might not have been considered in advance.    The most
commonly observed retrospective message reports that underflow exceptions
occurred.

4) Specific error messages for SIGFPE.   Although IEEE traps are not enabled
by default, they can be enabled by -fnonstd, and other kinds of arithmetic
exceptions always generate SIGFPE.   Distinguishing these cases prior to
abort is helpful but requires installing a trap handler to do so.

II.  Alternative

Since around 1990, the command-line option -fnonstd caused the floating-point
hardware to be initialized for nonstandard arithmetic, and for traps on
invalid, overflow, and division by zero.    That was intended to be suitable
for programs being ported from VAX VMS.   Because all the SPARC hardware at
that time ran faster with nonstandard arithmetic, -fnonstd got incorporated
into an option -fast which was a catch-all macro of compiler performance options
meant for people who were in too great a hurry to read the documentation.   
Later many people started using -fast more generally and not always
appropriately.

III. Documentation

Most of these features have been described in fair detail in the 
Floating-Point Programmer's Guide which accompanied SunOS 4.0 and its
successor, the Numerical Computation Guide, which has accompanied some
unbundled compiler products since then.

IV.  Assertions

Suggestions for altering the behaviors discussed above have revolved around
the following assertions.   Perhaps it would be helpful to others contemplating
such features if persons
with experience arguing for or against these
features would so testify to this mailing list,
especially end users and producers of mathematical software.

1)  Immediate termination is preferable to nonstop exception handling,
especially in debugging, and should be the default.   In general
continuing past exceptions wastes time.   All other Fortran compilers
(maybe all other compilers) by default
terminate immediately on invalid, overflow, and division by zero, and ignore
underflow and inexact exceptions; to the extent that Sun Fortran is 
different, it creates a porting problem.    (Like Sun Fortran, most other
compilers have command-line and programmable methods of obtaining other
behavior than the default.)
The amount of portable software written or being written that depends
on the nonstop feature is negligible compared to the amount of software that
is adversely affected by nonstop execution.

2)  The debugger should identify floating-point exceptions precisely in
terms of the source statement and variables causing the exception.
[In SPARC as with other RISCs, this means that barrier instructions have
to be generated at procedure boundaries and perhaps at statement boundaries.]
Fortran's default SIGFPE handlers confuse the high-level debugger.

3)  If not running under the debugger, exceptions should cause a traceback.
(Sun Fortran has provided tracebacks after certain conditions in some previous
releases.)

4)  The retrospective diagnostic information creates a portability problem.
It's not required by IEEE 754.
No other compilers provide it, and it's not consistent with Sun C and C++.
Turning retrospective diagnostics off by adding non-portable code is unpopular
with persons maintaining portable code.   
Unexpected diagnostics from third-party programs confuse end-users who
have no way of interpreting their significance or turning them off.
Numerous bug reports have been filed on this issue.
The retrospective message should be enabled as an option.

5)  For consistency,
the retrospective message should be produced even if the only information
is that an inexact floating-point operation has occurred. 

6)  -fnonstd should suppress the retrospective messages because people using
-fnonstd aren't going to know what to do with them.

7)  The nonstandard arithmetic and termination-on-exceptions aspects of
-fnonstd should be separated into different flags.

8)  Sun Fortran is an implementation of Fortran-77.    With various
rather different Fortran-90 compilers readily available 
from a number of sources, there is no particular
value in upward compatibility from previous implementations of
Fortran-77 in terms of the kinds of the non-universal
added-value features mentioned above.