Floating point exception handling

[john_keenan]

I have a C# user interface that calls a dll written in Intel Fortran 9.1.With certain input valuesthe Fortran calculations are generating floating point NaNs. In the Debug build I want an exception to be generated instead of NaNs so I can immediately identify the location thereby allowing me to inspect the calculation causing the exception and determine if an alternate value or alternate calculation should be used. I have changed the Property > Fortran > Floating point> Floating point exception handling to "Underflow gives 0.0; Abort on other IEEE exceptions" which seems to be exactly what I want but NaNs continue to be produced instead of exceptions. Is there something else I need to change to get the behavior I desire?

Am I correct in assumming that the floating point processor control word is changed when entering the fortran code and then returned to its previous state when exiting the Fortran code? In other words the state of the calling environment should have no affect on the Fortran floating point processor specification.

John

[Jugoslav_Dujic]

John.Keenan:

Am I correct in assumming that the floating point processor control word is changed when entering the fortran code and then returned to its previous state when exiting the Fortran code? In other words the state of the calling environment should have no affect on the Fortran floating point processor specification.

No. Even for code compiled with /fpe:0 (produce exceptions), exceptions can still be masked by the FPCW, which is outside of control of your dll. In my Dll I have:

integer, parameter:: FP_MASK= FPCW$INVALID.or.FPCW$ZERODIVIDE

integer(2)::                           iFp, iFpu

call getcontrolfpqq(iFpu)

#ifdef RELEASE

 iFp=ior(iFpu,FP_MASK)

#else

 iFp=iand(iFpu, not(FP_MASK))

#endif

call setcontrolfpqq(iFp)

at entry of every entry-point routine (well, actually, in one wrapper function, but the code is always executed). Probably the FPCW should be set back to the original value on return (so that the dll "plays nice").

[john_keenan]

JugoslavDujic:

No. Even for code compiled with /fpe:0 (produce exceptions), exceptions can still be masked by the FPCW, which is outside of control of your dll. In my Dll I have: ...

Thank you very much Jugoslav. That produced the behavior I was looking for.

I am now confused exactly what Property > Fortran > Floating point > Floating point exception handling to "Underflow gives 0.0; Abort on other IEEE exceptions" does do. I was under the impression the floating point control word was THE entity that determined whether or not floating point exceptions occurred.

John

[Steven_L_Intel1]

That setting primarly drives code in a Fortran main program that calls a routine called FOR_SET_FPE to set the FPCW. It doesn't do this for a DLL.

[Jugoslav_Dujic]

MADsblionel:

That setting primarly drives code in a Fortran main program that calls a routine called FOR_SET_FPE to set the FPCW. It doesn't do this for a DLL.

So, I have been under false impression that this setting actually affects the generated machine code? Driven by that impression, I wandered quite a bit how to reliably get the desired behavior (the same as John wanted). Now that you said it, it makes much more sense that way...

So, basically the only way to regulate exceptions is through FPCW, right?

Slightly off-topic, Steve, is my observation correct that math intrinsics now (as opposed to CVF) behave according to FPCW setting? For example, LOG(0) or SQRT(negative) now generate "Invalid FP operation" exception with appropriate FPCW flag cleared, rather than displaying arcane message box or terminate (thus MATHERRQQ is now deservingly retired).