Mail Archives: djgpp/2000/07/04/11:12:34
> From: Waldemar Schultz <schultz AT ma DOT tum DOT de>
> Newsgroups: comp.os.msdos.djgpp
> Date: Tue, 04 Jul 2000 15:33:52 +0200
>
> if I don't use FPE
> double a=0;
> double b=1;
> double c=b/a;
> double d=a*c;
> printf("%g %g\n",c,d);
> just prints 'Inf NaN'
Even if you unmask numerical exceptions in the FPU? What about the
FPU status word--does it have the corresponding exception bits set?
Note that recent versions of GCC get quite smart about such simple
code whose results are known at compile time, and might even optimize
the FP instructions out of existence, leaving only the bit pattern of
Inf/NaN that are loaded and returned.
> Because of the huge amount of math operations in the whole
> program it isn't feaseable to add something like 'if(fabs(a)<EPS) ...'
> ir 'if(!finite(c)) ...' before any aritmetic operation.
But you could place such checkpoints in strategic places and zero in
on the problem. (IMHO, you will want to leave these safeguards in the
production code anyway, whereas FP exceptions generally cannot remain
unmasked beyond the debugging period.)
> so forehand I think I will use a combination of both and try to avoid
> an environment where FPE is supposed to crash.
That means practically only plain DOS. In my experience, on DOS you
are safe (except under a debugger, where there are some complications).
> BTW: is it FPE or raise(SIGABRT) which causes the problems?
It's the exception itself, long before it gets converted into SIGFPE.
(To do this, DJGPP startup code installs a handler for Int 75h in
protected mode, and when the interrupt hits, it invalidates the DS
selector, exactly like the keyboard handler does with Ctrl-C.)
> print_symified_traceback(...); // anyone did that before ???
Yes. See the docs for the function __djgpp_traceback_exit. However,
SIGABRT is not your problem, so this won't help you.
- Raw text -