Date:	Mon, 22 May 2000 13:55:10 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Simple C program showing FPU problem !
In-Reply-To:	<200005221056.MAA19766@cerbere.u-strasbg.fr>
Message-ID:	<Pine.SUN.3.91.1000522134935.26547C@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 22 May 2000, Pierre Muller wrote:

>  I don't think that the FPU exceptions in the status word are cleared when
> interrupt of the primary running Make is called by the OS

Yes, it is.  I checked it: the lower byte is cleared.  I could ignore the 
exception on these grounds, but I decided that it's better to print a 
message instead, to let the user know that something went wrong.

>   The Intel docs above even explicitly say that the only
> safe way is to reset the exceptions inside the int 0x75 handler !

I didn't yet read that document closely, but if Intel says that, it's
IMHO a ridiculous advice, since it means that the handler hides the 
exception details from the application (by resetting the FPU before the
application gets a chance to look at it).  This is DOS, not Linux ;-)

> >This has the same drawback as ignoring the exception: signals that 
> >have their exception bits reset will not be reported to the application, 
> >since they look like no-exception condition.
> 
>   But if you want to simulate a FPU exception in C,
> you should use _raise(SIGFPE), not a call to interrupt 0x75 !

I didn't mean raising the signal, I meant the problems with Windows 
whereby the exception ends up in the parent program instead in the 
program that triggered the exception.

- Raw text -