IEEE exceptions and compilers

Peter Shenkin uunet!still3.chem.columbia.edu!shenkin
Fri Jan 27 07:40:41 PST 1995


On Jan 26,  9:34pm, David G. Hough at validgh wrote:
> Subject: IEEE exceptions and compilers

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

This last sentence is simply incorrect.  I've been working on SGI
compilers for many years, and they, like SUN's, by default continue
past IEEE exceptions.  So do the IBM RS/6000 and the HP PA-RISC
compilers.

I personally feel that the default Sun has selected is sensible, and
contrary to the anonymous asserter's assertions, I feel that this
view is strengthened by the fact that Fortran compilers on most
UNIX workstations use the same default behavior.

> 2)  The debugger should identify floating-point exceptions precisely in
> terms of the source statement and variables causing the exception.

I'm in favor of providing simple methods to simply dump core or
halt upon discovering an exception;  if run in this manner, then, yes,
this information should be provided.  A traceback would also be useful.
Additional suggestion:  flush print buffers before halting.

> 3)  If not running under the debugger, exceptions should cause a traceback.

See above.

> 4)  The retrospective diagnostic information creates a portability problem.
> It's not required by IEEE 754....

Here I agree.  The stdout output seems gratuitous to me, and what's even
worse is that in order to turn it off, one has to compile in a special
routine.  At the very least, on ought to be able to turn it off with
compile-time flags and run-time mechanisms (i.e., environment variables).

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

No opinion.

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

It seems to me that if the program is run in such a way that you abort
on an IEEE exception, the retrospective messages won't hurt and might
even help.

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

Sounds reasonable.

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

Mild disagreement.  One expects ones old Fortran code, when compiled
with vendor X's new Fortran-90 compiler, to behave the same way it
used to behave when compiled with vendor X's old Fortran-77 compiler.

Summary:  I think Sun picked the correct default (follow IEEE 754) on
exception handling.  I don't use Suns, but I'm certain I wouldn't
like the retrospective reporting feature -- especially since I can't
control it by compile-time flags or runtime environment variables.
I'd like to have both sorts of control, and not have to compile in
a special routine.

Remark:  I very much like the way SGI handles exception handling.  If
you simply compile with "-lfpe" and do nothing else, then, depending
on the value of the environment variable TRAP_FPE, you can control
the IEEE-exception behavior of the application.  For example,
	setenv TRAP_FPE UNDERFL=ABORT
makes an underflow cause a core dump.

	-P.


	-P.


-- 
************************ The secret of life: *************************
*Peter S. Shenkin, Box 768 Havemeyer Hall, Chemistry, Columbia Univ.,*
* New York, NY  10027;     shenkinacolumbia.edu;     (212) 854-5143  *
************* If you find a loose thread, don't pull it. *************




More information about the Numeric-interest mailing list