IEEE traps in C

[David Hough]

Alan M. McKenney raises some issues about enabling IEEE traps in 
comp.os.linux.development.system, and there have been other discussions
started by Dean Schulze in comp.os.linux.misc about paranoia.

The long and short of it is there isn't any standard way in source code
to set modes like x86 rounding precision or invalid exception trap enable.
On SunOS 4 and 5 you can use ieee_flags(3m) and ieee_handler(3m) to do these
things.    The NCEG extensions proposals include ways of doing some of these
things as well.     

One problem specific to the x86 rounding precision modes is that if the 
default is set to round-to-double, more programs that were written without
extended precision in mind work better, while if the default is set to 
round-to-extended, programs that were written with extended precision in mind
won't work at all.    Since the programs in question are usually in subroutine
libraries rather than in the main program, they may need to save, set, and
restore floating-point modes if they are to be conscientious.

One problem specific to trap enables is that many PC compilers and some
workstation compilers enable certain IEEE traps by default, namely overflow,
division by zero, and invalid, which is nonstandard.   On Sun's SPARCcompilers
the compile-time option -fnonstd can be used to do that, but nonstandard
behavior is not the default.

> 1.  This appears to me to be part of a larger tendency to ignore
>     floating-point exceptions.  More and more, I read postings from
>     people complaining that a code that ran without bombing on
>     system A (with traps masked off by default) bombs on system B
>     (with traps enabled by default), asking how to disable traps.
> 
>     I doubt that these posters have carefully coded their
>     entire code to get correct (or reasonable) results even with
>     Inf's and NaN's as intermediate results; it seems more likely
>     that they have been lulled by the IEEE-specified no-trap
>     behavior into not taking divide-by-zero or overflow seriously.
> 
>     This *should* be of concern to those who care about whether
>     floating-point code produces reasonable or totally bogus
>     answers, which I assume includes the readers of this mailing
>     list.

Of course, most incorrect numerical results produced by programs are due 
source program bugs and optimizer bugs and incorrect input data, but aside
from those kinds of issues, the most common problem is roundoff.   But 
roundoff occurs during most programs deliver correct results, too, and there
isn't any way to distinguish good from bad except by human or automatic
analysis.     That's why interval methods are so important - they encompass
errors in the input data and its conversion to binary, in truncating analytic
processes to computational ones, in roundoff due to finite precision, AND
they handle underflow and overflow in a useful way as well.

IEEE 754 doesn't require that implementations provide a trapping capability,
but all PC's and I think all current RISC workstations have some such 
capability in hardware that is more or less difficult to use.    
Non-IEEE systems
often have no convenient way to disable traps that are enabled by default.
It would be helpful indeed 
to have a standard way of doing what Sun's ieee_handler
does - enable/disable a trap if possible, causing a SIGFPE; it returns 
a failure indication if no trapping is possible, as on Sun-3's with no
floating-point hardware, but not on any current Sun systems.   The problem 
lies in defining what "enabling a trap" means in general, which is an
impediment to standardization; perhaps enable_sigfpe would be more appropriate
for C since its standard says a little bit about signals.

> 3.  I remember W. Kahan giving a talk on floating-point exceptions,
>     and what you could do with flexible exception handling; this
>     sounds like something of interest to this mailing list.
> 
>     However, this cannot be done (in present systems) without
>     having trap handlers, and ones that are given a fair amount
>     of FPU state.
> 
>     Instead, the trend seems to be not to give trap handlers any
>     information, not even what exception(s) occurred or where
>     it/they occurred.

The FPU state is always machine-dependent in detail, and so it's hard for the
end user to
write a trap handler that depends very much on that.    However it makes
sense for a standard
to require a few general capabilities in a machine-independent way
and leave the details to the system vendors to implement.

It's an ongoing discussion as to whether it's worthwhile to provide precise
traps in hardware; 
this has all kinds of system ramifications, and while it can be done
sometimes without apparent performance penalties, 
that makes the system harder to design
and get right, and so later to market, and so lower in performance after all, 
since time to market and performance can be largely traded off.    
Perhaps the most
difficult argument against precise traps is that unless most systems provide
them, "nobody" will use them, meaning the ISV's that provide mass-market
software.