Questions on Exception handling

rahzan · ‎09-15-2003

I am fooling with the c-wrapper idea to catch runtime errors:

1. On the lines:
select case( recordInfo.ExceptionCode)
case(STATUS_FLOAT_DIVIDE_BY_ZERO)
....
I get:
Warning: Case selection values must fit within a signed 32 bit integer. Value truncated.
case(STATUS_FLOAT_DIVIDE_BY_ZERO)
which constants should one use which are 32 bit??

2. What is the use the "record Context"?
I see that it has a member called Flags and 7 others DR0-DR7 (data registers?) but I do not know what the constants to comapre them to, and what they mean.

3. After an exceptino, a call to TRACEBACK generates a DISPLAY of the error stack, I instead need to simply catch the line number of the failure and display my own error msg. Is there a way to just get the line number(s)? If not, is there a way to route the display of the TRACEBACK to a file or data structure to be parsed in code?

4. Steve: Do you know if this c-wrapper method is supported in IF7?

Thanks,
Tim

Jugoslav_Dujic · ‎09-16-2003

As for 1), Tim, I think we've been there already? You have an old version of DFWINTY.mod somewhere.

If I have to guess, I'd say that you either have a mess in INCLUDE variable and/or Tools/Options/Directiories/Include file setting, or that an earlier upgrade failed to replace .mod files from DF98Include directory.

As for 2-4, I don't know. I'm not a god ;-).

Jugoslav

gfthomas8 · ‎09-16-2003

> 1.

Jugoslav has dealt with this.

> 2. What is the use the "record Context"?

See winnt.h for all the gory details. The struct is cpu dependent, it's how Windows remembers threads as it flits from one to the other, and when an app throws an exception examing its flags gives info on the exception.

eg,
type(T_CONTEXT) :: ctxptr
pointer(ctxp,ctxptr)
logical(4) :: res = .false.
:
!Clear integer overflow flag
if (btest(ctxptr.EFLAGS,11)) res = ibclr(ctxptr.EFLAGS,11)
!IAND(ctxptr.FloatSave.StatusWord,16#FFFFFFC0)
ctxptr.FloatSave.StatusWord = 0
:

> 3.

This is very well described in the CVF documentation.

> 4.

Not speaking for Steve, no within VS.NET

Ciao,
Gerry T.

Steven_L_Intel1 · ‎09-16-2003

IF7 doesn't have traceback. I can't say whether the wrapper is "supported", in the sense that Intel will help you if it doesn't work, but I don't know of any reason it shouldn't work.

Steve

rahzan · ‎09-16-2003

Thank you all.
Feels like the answers are too obvious, alas, I'm still not clear on 1 and 3 below.

1. I searched the entire system and there is only one DFWINTY under DFINCLUDE and the .f90 is dated 7/15/2002 and the .mod is dated 8/9/2002. Where can I find a more recent version?

2. I looked up the WINNT.H. It looks like the information is not that useful for regular-guy error catching purposes. I will forgo the trouble.

3. I _have looked in the documentation about how to get the traceback info without calling TRACEBACKQQ (and getting its display). Any hints will be appreciated.

4. I'm glad to hear the trick will contunue to work in IF7+. There is not much to it so as to need help really. I was concerned mostly about how to tell IF about the necessary c-compiler in the vs.net which I assume must be either of midl or msc6.

Tim

gfthomas8 · ‎09-16-2003

The wrapper requires a mixed language project. Are you implying that this can be done within VS.NET using IFC or VF? What happened the Great Wall of Microsoft?

Ciao,
Gerry T.

gfthomas8 · ‎09-16-2003

1. Try
:
type(T_EXCEPTION_RECORD) :: erecptr
:
if(erecptr.ExceptionCode == EXCEPTION_ACCESS_VIOLATION) then
:
elseif(erecptr.ExceptionCode == EXCEPTION_DATATYPE_MISALIGNMENT) then
:
else
:
endif

2.

All winnt.h requires is curiosity.

3. Look up SETENVQQ.

HTH,
Gerry T.

Steven_L_Intel1 · ‎09-16-2003

Re: "great wall"

This does not require a mixed-language project. It requires a mixed-language application. In VS.NET, this has to be implemented as multiple projects in a "Solution".

Steve

rahzan · ‎09-16-2003

Sorry to be dense,
but I do not see how SETENVQQ can help with obtaining the line number info available in the TRACEBACKQQ display.

Also I'd appreciate it if anyone can point out a way of getting the versions of DFWINTY.* more recent than 7/15/2002.

Tim

gfthomas8 · ‎09-16-2003

> Re: "great wall"
>
> This does not require a mixed-language project. It
> requires a mixed-language application. In VS.NET,
> this has to be implemented as multiple projects in a
> "Solution".
>

Please direct the forum to an IFC sample demonstrating the validity of your claim, ie, show us an IFC Fotran application that implements SEH via a Solution in VS.NET.

Ciao,
Gerry T.

gfthomas8 · ‎09-16-2003

> Sorry to be dense,
> but I do not see how SETENVQQ can help with obtaining
> the line number info available in the TRACEBACKQQ
> display.
>

:
logical(4) :: res = .false.
:
!Dont throw exceptions at the console
res = SETENVQQ("FOR_DISABLE_DIAGNOSTIC_DISPLAY=F")
if (res == .false.) then
res = SETENVQQ("FOR_DIAGNOSTIC_LOG_FILE="//TempPath//"MyBigError.log")
endif
:
Note: turn traceback 'on' and supply your TempPath.

> Also I'd appreciate it if anyone can point out a way
> of getting the versions of DFWINTY.* more recent than
> 7/15/2002.
>

Ask vf-support for this or do a reinstall.

BTW, Fortran apps that include support for traceback and structured exception handling without mixed-language fussing and with full integration into VS.NET is available in Lahey's Fortran.NET

HTH,
Gerry T.

Steven_L_Intel1 · ‎09-17-2003

Please direct the forum to an IFC sample demonstrating the validity of your claim, ie, show us an IFC Fotran application that implements SEH via a Solution in VS.NET.

Gerry, I believe you misunderstood me. I simply said that it was still possible to build mixed C-Fortran applications - it is just done differently. I said nothing about SEH other than that I didn't know of any reason why what worked with CVF wouldn't also work with ifl.

Steve

gfthomas8 · ‎09-17-2003

> Please direct the forum to an IFC sample
> demonstrating the validity of your claim, ie, show us
> an IFC Fotran application that implements SEH via a
> Solution in VS.NET.
>
> Gerry, I believe you misunderstood me. I simply said
> that it was still possible to build mixed C-Fortran
> applications - it is just done differently. I said
> nothing about SEH other than that I didn't know of
> any reason why what worked with CVF wouldn't also
> work with ifl.
>

The issue in question was whether, like CVF, IFC admitted SEH with traceback in a mixed-language project. The answer, as I said, is an emphatic NO. The reason is two-fold: it doesn't yet have traceback (but presumably that is coming) but, more importantly, the barrier between languages within VS.NET precludes building a link-compatible mixed-language project. Multi-language applications or 'solutions' are the norm for all languages within .NET, including IFC. Unfortunately, that doesn't allow you to implement SEH via a C wrapper in IFC. Perhaps Intel should consider implementing SEH support within IFC/VF just as it's available to VB, C#, C++, and Lahey Fortran.NET, Great Wall of Miscosoft be damned.

Ciao,
Gerry T.

Steven_L_Intel1 · ‎09-17-2003

Gerry, you are getting sidetracked by the term "project". It is certainly possible to build an executable or DLL that contains code in both Fortran and C++ with Intel Fortran. The steps for doing so are different and somewhat more difficult than with CVF, but not onerously so in nearly all cases. The one case I cna think of that can be a headache is if you want to build a static library with mixed language code. It can be done, but it's complicated.

I'm travelling this week so am not easily able to construct an example for you, but I'll try to do so when I return to the office next week.

I note that you keep referring to Lahey Fortran for .NET as being the ideal solution to mixed-language applications. I will point out that Lahey Fortran for .NET also is constrained by Microsoft not permitting mixed-language projects, and that you build a mixed-language application in a way that is not too different from using Intel Fortran. I would also direct your attention to the Polyhedron performance test results.

Steve

hweisberg · ‎09-19-2003

A C wrapper for Fortran DLLs that implements SEH would be generally useful. If done correctly, it would require essentially no customization per project. Just include it in your DLL project and wire it to the entry point of the DLL.

gfthomas8 · ‎09-23-2003

> Gerry, you are getting sidetracked by the term
> "project". It is certainly possible to build an
> executable or DLL that contains code in both Fortran
> and C++ with Intel Fortran. The steps for doing so
> are different and somewhat more difficult than with
> CVF, but not onerously so in nearly all cases. The
> one case I cna think of that can be a headache is if
> you want to build a static library with mixed
> language code. It can be done, but it's
> complicated.
>
> I'm travelling this week so am not easily able to
> construct an example for you, but I'll try to do so
> when I return to the office next week.
>

I'm sure that more than a few here would be interested in such a sample. Assuming that it can be done, will IVF have a Wizard or AddIn for such a task?

> I note that you keep referring to Lahey Fortran for
> .NET as being the ideal solution to mixed-language
> applications. I will point out that Lahey Fortran
> for .NET also is constrained by Microsoft not
> permitting mixed-language projects, and that you
> build a mixed-language application in a way
> that is not too different from using Intel Fortran.
> I would also direct your attention to the Polyhedron
> performance test results.

Two points:
1. Fortran.Net has build-in support for traceback and exception handling in a single language (Fortran no less).
2. Polyhedron is verboten to me although I did notice the summary results posted to c.l.f:
CVF Compaq Visual Fortran 6.6
Intel Intel Fortran Compiler 7.1
Lahey.NET Lahey Fortran for .NET 7.00.00
I can't tell if the differences between these three results are significant. Anyway, it's early days for .NET and execution times can only improve.

Ciao,
Gerry T.

gfthomas8 · ‎09-30-2003

> Gerry, you are getting sidetracked by the term
> "project". It is certainly possible to build an
> executable or DLL that contains code in both Fortran
> and C++ with Intel Fortran. The steps for doing so
> are different and somewhat more difficult than with
> CVF, but not onerously so in nearly all cases. The
> one case I cna think of that can be a headache is if
> you want to build a static library with mixed
> language code. It can be done, but it's
> complicated.
>
> I'm travelling this week so am not easily able to
> construct an example for you, but I'll try to do so
> when I return to the office next week.
>
[...]

Welcome back Steve. How's the progress on this example coming along?

Ciao,
Gerry T.

Steven_L_Intel1 · ‎10-01-2003

I was trying the CVF CSLEXCP4 sample, but Intel Fortran 7 doesn't like a lot of the language constructs in it, and doesn't support /fpe:0. What exactly are you interested in? Would a normal (not exception handling) mixed Fortran-C solution be satisfactory? That is easy.

Steve

gfthomas8 · ‎10-02-2003

A minimalist Intel Fortran-C sample built within .NET 2003 (no use of cmd line please) would be fine. I'm interested in comparing and contrasting with CVF in VS98.

Thanks,
Gerry T.

Steven_L_Intel1 · ‎10-02-2003

Ok, piece of cake. Should have it for you later today (after I take care of a few things...)

Steve

Steven_L_Intel1 · ‎10-02-2003

Here you go. This is for Intel Fortran 7.1 in VS.NET 2002.

Steve