Floating Point Exception Handling -- FPU stack

[JasonD]

After unmasking all floating point exceptions with _controlfp() (which sets the the floating-point control word), like so:

_controlfp(0,_MCW_EM);

so that all floating point exceptions are thrown, instead of masked (the default), I handle the SEH exceptions with __try and __except, being sure to call _clearfp() in the exception handler before any other FP instructions.

Now, to test each individual floating point exception that is possible, I create a bunch of floating point code to cause such exceptions, and watch them be caught. I have done this successfully (being sure to use exact binary representations so that the STATUS_FLOAT_INEXACT_RESULT exception doesn't hide another exception, such as STATUS_FLOAT_OVERFLOW).

But, my problem is that after 8 successive FP exceptions handled, every further FP exception handled is STATUS_FLOAT_STACK_CHECK no matter what the floating point code does.

IIRC, there are only 8 floating point registers on the FPU. So, it looks like the FPU stack is not reset during exception handling. I suppose this makes sense, since hardware exceptions (SEH) are asynchronous. Thus, the FPU stack is left as-is. Calling _clearfp(), which clears the FP status word, does not reset the stack, as that is not its job.

The only way I can solve the problem is to call _fpreset() which resets everything -- including turning on exception masking. Thus, I have to turn it back off again. Is there any other way to reset the FP stack?

Perhaps a better question: What is the proper way to handle a FP exception? (and why doesn't MSDN tell us?) Without resetting the stack, after 8 FP exceptions caught, your application will be in a mess. What a way to find out such a devastating bug. There must be a properly documented way to handle these.