[Ecls-list] FPE signal catching produces hazardous resultsunder MSVC

[Goffioul Michael]

> On Tue, 2005-10-25 at 12:08 +0200, Goffioul Michael wrote:
> > Problems start to appeard after generating a lot of FPE 
> successively. After that,
> > FPE starts to appear at places where it shouldn't and 
> depending on the previous
> > operation....?? Here's a session example (see how the (<= 
> (REALPART...)) statement
> > generates a FPE, sometimes it doesn't):
> 
> I do not know if this is related, but the processor has other
> exceptions, such as FPE_INEXACT, and when I activated it, I 
> got lots of
> errors due to the compiler generating comparisons between floats and
> doubles. Can it be that the control word bits for FPE_INEXACT get set?

Normally not. By default, all FPE are disabled and the code only enable
FE_OVERFLOW, FE_UNDERFLOW and FE_DIVBYZERO. Moreover, my FPE handler
really gets called with FE_OVERFLOW (in the example of my previous mail),
not FE_INEXACT.

Note that on the doc page for _controfp() on MSDN, I found this info,
but I don't know if this is related (my exception handling knowledge
is not exhaustive):

	Note that if a _EM_UNDERFLOW or_EM_OVERFLOW occurs, no hardware
	exception will be thrown until the next floating point instruction
	is executed. To generate a hardware exception immediately after
	_EM_UNDERFLOW or_EM_OVERFLOW, call the FWAIT MASM instruction.

Michael.