IEEE traps in C

[Alan M. McKenney]

David Hough writes:

> ... The NCEG extensions proposals include ways of doing some of these
> things as well.     

    I must confess, this left me unclear as to whether what I had
    heard was correct.  However, Fred J. Tydeman
    <tydemanatybor.com> confirmed that, indeed, the NCEG proposal
    does not mention traps or trap handling.

<stuff about rounding modes deleted, as they have nothing to do with traps.>


> 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.

    Some consider this a "problem", I consider this a life-saver.

    [> A. McKenney continues:]

> > 1.  This appears to me to be part of a larger tendency to ignore
> >     floating-point exceptions.

<snip>


> >     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.  ...

    Actually, I (like most readers of this list, I suspect) am aware of
    this.  My comments were intended more as a call-to-arms (or, if
    you prefer, rabble-rousing.)


    My concern is this:

	The trend appears to be towards *not* trapping (whether
	to abort or otherwise) on an exception, and to provide
	*no* facility to do so, either.  I consider this a step
	*backwards.*   I urge all those who believe in truth,
	justice, and right answers to fight this trend.


    I grant you, not all errors which produce wrong answers also
    generate floating-point exceptions.  However, since 99% of
    all exceptions are due to bugs, and moreover all
    floating-point hardware that I know of provides this
    facility, it seems strange to ignore exceptions.  No one
    would propose ignoring fetches from non-existent memory (what
    Unix calls "segmentation violation".)

    (BTW, I am specifically considering general-purpose computers.
    So please, nobody start talking about embeded systems.)


> 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.

    However, I believe it was here that I read that interval methods are
    still only useful to a small class of problems.  We are not yet
    ready to swap our 80387s for interval FPUs.


> 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.


    I would be happy if everyone would start implementing Sun's
    ieee_* calls.  Sun is, in my experience, the only vendor to
    provide a decent interface to access the IEEE functionality.

    Does Sun consider the specification of the ieee_* calls proprietary?
    If not, maybe we could whip up a standard real quick :-)

>   ....   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.

    I don't understand your distinction between a "trap" and a "signal."
    The issue is: what happens when your program, e.g., divides by
    zero: continue, crash, or call a subroutine.  Unix calls this
    a signal.  Other people refer to this as a trap.



Alan McKenney        E-mail:  mckenneyacims.nyu.edu         (INTERNET)
Courant Institute,NYU,USA     ...!cmcl2!cims.nyu.edu!mckenney   (UUCP)