Message-Id: <200007041511.SAA04094@alpha.netvision.net.il>
Date: Tue, 04 Jul 2000 18:12:51 +0200
To: Waldemar Schultz <schultz AT ma DOT tum DOT de>
X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
CC: djgpp AT delorie DOT com
In-reply-to: <3961E7C0.178AC0B6@ma.tum.de> (message from Waldemar Schultz on
	Tue, 04 Jul 2000 15:33:52 +0200)
Subject: Re: Floating point exception
References: <39608EF6 DOT FC0856D1 AT ma DOT tum DOT de> <200007031820 DOT VAA11428 AT mailgw1 DOT netvision DOT net DOT il> <3961E7C0 DOT 178AC0B6 AT ma DOT tum DOT de>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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