Date: Mon, 22 May 2000 13:55:10 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Pierre Muller 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.