This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Alpha vs EXCEPTION_TESTS


Alpha fp arithmetic has multiple modes of conformance to IEEE,
with increasing performance impact.  The "normal" ieee-enabled
mode has inexact exceptions disabled, but detects others.

We've had this as the default since time immemorial, because
none of the cpus manufactured ever implemented inexact exceptions
in hardware.  If the cpu thought that inexact might be possible,
it would trap to the kernel for full emulation.

IIRC, the last ev67 cpus did a fairly good job of not trapping
for operations that wouldn't result in inexact, but the early
cpus didn't even bother attempting the operation -- all insns
with the /i (inexact enabled) flag set would trap.  In fact,
the earliest ev4 versions didn't even decode the insn -- thus
the strange route into the kernel's soft-fp routines coming
from the illegal opcode handler rather than the expected
software fp handler.

Thus the current state of affairs wherein if one really wants
the inexact flag to be correct throughout libm, one has to rebuild
the library with -mieee-with-inexact set in cflags or whatever.
(Those few files like fma for which we rely on inexact for correct
results have individual CFLAGS-foo variables set in the Makefile.)

With the recent enhancements to the testsuite, we now have

> testing float (without inline functions)
> Failure: scalbn (1, INT_MAX): Exception "Inexact" not set

etc.

I'm wondering if there were ideas about the best way to adjust
the EXCEPTION_TESTS macro to filter the implemented exceptions.

On the one hand we have

>   if (EXCEPTION_TESTS (float) && fetestexcept (FE_OVERFLOW) == 0)

where a change like

  if (EXCEPTION_TESTS (float, FE_OVERFLOW) && fetestexcept (FE_OVERFLOW) == 0)

i.e. have EXCEPTION_TESTS take an extra argument but still return
a boolean would make sense.  OTOH, we also have

>   int fe = fetestexcept (FE_ALL_EXCEPT);
>   if (EXCEPTION_TESTS (float) && fe != (FE_OVERFLOW | FE_INEXACT))

where a change like

  if ((EXCEPTION_TESTS (float) & (FE_OVERFLOW | FE_INEXACT)) != fe)

i.e. have EXCEPTION_TESTS return a mask of supported exceptions
seems the only feasible change.

Thoughts?  Other possibilities?


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]