Error Handling

[Intel_C_Intel]

I'm investigating the error handling routines in CVF 6.6B no Win2000. I have a DLL with a subroutine where I generate FP errors (anyone know how to generate a denormal??). My code was working fine by getting the FPE status before and after my error generation, and then interpreting it.

I then wanted to try SIGNALQQ instead - since jumping out at the time of generation could be more useful. I've set up my FPE signal routine as per the supplied examples, I set /fpe:0 for my DLL. But I can't get a jump to my handler routine from my exception generating code (I can get there from RAISEQQ though ...)

My main app is compiled /fpe:3 and calls the FORTRAN from within a C++ __try ... __catch. Do I need to remove all my FPE handling for SIGNALQQ to work?

Cheers,

Dan

[Steven_L_Intel1]

A lot of error handling requires an exception handler to be established, and this is done in a main program, not for a DLL. In addition, things such as /fpe:0 require changing the FP status registers, and no code to do that is added to a DLL.

You may want to read the chapters of the Visual Fortran Programmer's Guide on exception handling for tips on what you can and cannot do. If all you have is a DLL, your options are somewhat limited.

Steve

[gfthomas8]

> ... anyone know how to generate a denormal??...

Use the RaiseException API but ensure that denormals are not masked.

> I then wanted to try SIGNALQQ instead - since jumping
> out at the time of generation could be more useful.
> I've set up my FPE signal routine as per the supplied
> examples, I set /fpe:0 for my DLL. But I can't get a
> jump to my handler routine from my exception
> generating code (I can get there from RAISEQQ though
> ...)
>
> My main app is compiled /fpe:3 and calls the FORTRAN
> from within a C++ __try ... __catch. Do I need to
> remove all my FPE handling for SIGNALQQ to work?
>

It beats me why you want to differentiate between fpe's and all manner of other exceptions that are possibe and probable - memory related, debugging related, exception related, integer related. Write a handler that takes care of all. DLLs are for the intrepid. Set the cw programatically, forget signalqq, raiseqq, and /fpe. Work the tracepack capabilities into your handler. See if having a DllMain.c does anything for you.

Good Luck,
Gerry T.

[Intel_C_Intel]

Gerry,

We reverted to manual interpretation of FPEs...its easier.
I was only doing this in a DLL for convenience in slotting it into the main app, its the main app we'd want to debug.

We need to differentiate because we use bit masking to create 'special' real values that happen to be NaN's (hence /fpe:3). It's nice to tell if our model code (or user's model code!) generates 'real' NaNs from FPEs. Once the NaN is passed around a few iterative solvers and run through a bunch of models its everwhere in the database and trying to determine where it first entered is a nightmare (practically impossible).

Dan