[Openmcl-devel] more ansi-test bugs

[Gary Byers]

On Thu, 7 Dec 2006, Eric Marsden wrote:

> Hi,
>
> Some more bugs revealed by the ansi-test suite, still on Linux/AMD64.
> Congratulations for all the quick fixes !

I can usually put bugs in faster than I can take them out.

Here's a poll question (inspired by several cases in the test
suite) ...

ANSI CL says that an error "should be signaled" if the result of
a floating-point compilation yields exponent overflow or underflow
(12.1.4.3).  "should be signaled" implies that the error might
not be signaled in unsafe code, but that it must be signaled
in unsafe code.

ANSI CL also allows (and arguably encourages) implementations to
support IEEE denormalized numbers, which are conceptually at least the
product of exponent underflow.  (If one were to take 12.1.4.3
literally, implementations are free to support denormalized numbers,
but many operations on them - such as

(- least-positive-single-float 0.0f0)

would be required to signal errors in "safe code".)

Being compliant with 12.1.4.3 would probably require that underflow
traps be enabled in the FP hardware (and may also require that the
implementation avoid using the OS's standard math library if it does
not comply with 12.1.4.3's requirements, interpreted literally and
pedantically.)  I'm not too concerned about being "pedantically
compliant" with aspects of the spec that are incomplete/inconsistent,
but I am concerned about being consistent and offering means of overriding
the default behavior (whatever it is ...) when it's necessary to do
so.

There are functions in OpenMCL that allow one to get and set IEEE
FP parameters (enabled exceptions, rounding mode) that apply to the
current thread.  These should be documented and exported (I think
that they're actually exported in some cases but not documented),
and it should be possible to use them to write things like:

(with-floating-point-underflow-disabled
   (computation-that-may-underflow))

to (possibly) get a denormalized result rather than an underflow
exception and:

(with-floating-point-underflow-enabled
   (computation-that-may-underflow))

to help ensure that an exception will be signaled.  (It may still be
hard to guarantee - as a pedantic interpretation of 12.1.4.3 may
assume - that IEEE-compliant exceptions would be signaled by some math
library functions; practically any implementation of these functions
is likely to be compliant with -some- C standard, which is one of
the benefits of having lots of standards ...)

The poll question involves the most appropriate default: is it better
in practice for the default behavior to be "underflow disabled,
operations on/returning denormalized floats are fully supported" or
"underflow enabled, operations which return denorms generally signal
FLOATING-POINT-UNDERFLOW" ?