On Thu, 7 Oct 2004, Tim Jenness wrote:
> A bit more digging indicates that there is a Gnu extension that enables
> SIGFPE with normal floating point exceptions.
>
> feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
>
> this indicates that we can retain the current SIGFPE trapping approach
> used for Solaris and have a gcc-specific implementation to enable SIGFPE.
> The reason for the exception can then be examined using fetestexcept().
Spent a couple of hours looking at this last night. feenableexcept really
does trigger SIGFPEsignals and you really can decode what type of signal
you got from the siginfo argument.
Unfortunately, once the signal has been handled the signal handler is
called repeatedly. I can't work out how to clear the signal state to stop
from being called an infinite number of times. A quick read of Advanced
Unix Programming suggests that SIGFPE should be treated much like SIGSEGV
in the sense that once you get one you should _exit immediately, maybe
with a descriptive error message if you want to be portable. Unfortunately
that doesn't help PRM.
Bottom line here is that to get NaN/Inf trapping working on linux the only
option is to use the C99 interface to the FPE exception flags. I still
don't know how to trap a X/0 (integer) though so do the integer routines
for dividing two numbers have special .EQ.0 traps in them?
These flags can then be used to decide whether an array needs fixing up or
not.
>
> This means that internally VEC_ routines can still use the NUM_ERROR
> common block. External calls (eg kappa and ccdpack) to NUM_WASOK will
> work but may be slow. In those cases it may be necessary to do the fix up
> with KPG1_IEEE after the loop.
>
> KPG1_IEEE[DR] could usefully be moved into PRM I think since that seems to
> be a sensible place for it.
>
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|