Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28383 Discussions

Forcing Debugger to break on exception

Stephen_Painchaud
967 Views

I have what I believe to be a floating point overflow near the end of a very long do loop. I would like the debugger to break when it reaches the exception. I have tried setting /fpe:0 in the user interface to no avail. I have the floating point model set to source (/fp:source), and enabled thereliable floating point exceptionsmodel(/fp:except). I am using IVF 11.0.066 and VS2005.

I would like to see what is happening at the moment the overflow occurs, but I don't want to manually step to the end of the long do loop.

0 Kudos
13 Replies
Les_Neilson
Valued Contributor II
967 Views

I have what I believe to be a floating point overflow near the end of a very long do loop. I would like the debugger to break when it reaches the exception. I have tried setting /fpe:0 in the user interface to no avail. I have the floating point model set to source (/fp:source), and enabled thereliable floating point exceptionsmodel(/fp:except). I am using IVF 11.0.066 and VS2005.

I would like to see what is happening at the moment the overflow occurs, but I don't want to manually step to the end of the long do loop.


If you know (even approximately) what the value of the loop counter is when the exception occurs, you could put a conditional breakpoint at the top of the loop. Put a breakpoint there and right click on it, select Condition, and in the boxenter
"loopcounter"=="somevalue"
or
"loopcounter">"somevalue"

This will break when the condition is reached and you can then step until the exception occurs and allowing you to watchthe variables.

Les
0 Kudos
Stephen_Painchaud
967 Views
Thank you. I was searching for something like this in the debug menu. I need to remember to right-click everywhere.

0 Kudos
Stephen_Painchaud
967 Views
I found out my problem. I had set /fpe:0 in a library project. This is not sufficient. Once I set the main project to stop on exceptions, the code stops on my first overflow.

0 Kudos
Jugoslav_Dujic
Valued Contributor II
967 Views
I found out my problem. I had set /fpe:0 in a library project. This is not sufficient. Once I set the main project to stop on exceptions, the code stops on my first overflow.


Frankly, existence of that switch is sort of mystery to me. If I get it correctly, the /fpe:XXX switch does not affect the emitted machine code at all -- it merely "inserts a call" to _controlfp (aka SetControlFPQQ or _control87) somewhere in the .exe's startup code. If you don't build an .exe, the switch basically has no effect.

In my opinion, the /fpe:X switch should push, alter and pop FP settings at the prolog/epilog of every routine (unless it's too performance-expensive). According to this Intel document, it is done by single instruction (FXSAVE/FXRESTORE) so it shouldn't be too complex. Numerical computing is not my area though, so I'd rather let others comment.
0 Kudos
Ron_Green
Moderator
967 Views
Quoting - Jugoslav Dujic

Frankly, existence of that switch is sort of mystery to me. If I get it correctly, the /fpe:XXX switch does not affect the emitted machine code at all -- it merely "inserts a call" to _controlfp (aka SetControlFPQQ or _control87) somewhere in the .exe's startup code. If you don't build an .exe, the switch basically has no effect.

In my opinion, the /fpe:X switch should push, alter and pop FP settings at the prolog/epilog of every routine (unless it's too performance-expensive). According to this Intel document, it is done by single instruction (FXSAVE/FXRESTORE) so it shouldn't be too complex. Numerical computing is not my area though, so I'd rather let others comment.

You do understand the current behavior, the FP settings are done by the exe in the startup. So yes, applying it to a library has no effect.

For the next major version one of our top feature requests is to do what you propose in your second paragraph: to set/restore the FP settings on a routine basis (since the option applies at the source level, you would get this for all routines in that source file. Pehaps some compiler directives to further enable/disable or control on a procedure-by-procedure basis.). This then would work on library code. No guarantees or timelines though, this is still in the preliminary planning phase and will still have to pass budgeting.
0 Kudos
gfthomas8
Novice
967 Views

You do understand the current behavior, the FP settings are done by the exe in the startup. So yes, applying it to a library has no effect.

For the next major version one of our top feature requests is to do what you propose in your second paragraph: to set/restore the FP settings on a routine basis (since the option applies at the source level, you would get this for all routines in that source file. Pehaps some compiler directives to further enable/disable or control on a procedure-by-procedure basis.). This then would work on library code. No guarantees or timelines though, this is still in the preliminary planning phase and will still have to pass budgeting.

This behavior was available in CVF and IVF up to 9.1 (with a minor release dependency). Then it got broken or fixed. Worse, some genius decided that IVF ought to stymie any attempt to break on an exception, not just a FP one, raised by the OS (that would be Windows) or by design through a Win API call and unashamedly crash.It would be nice to have the handiwork of whoever orchestrated this aberrant behavior reversed and to have IVF restored toplaying well with itschosen platform.
0 Kudos
Steven_L_Intel1
Employee
967 Views
Gerry, please provide a test case that demonstrates the problem you describe. I can't puzzle it out from your description.
0 Kudos
gfthomas8
Novice
967 Views
I've done so in the past and I am not inclined to do so again. I was also led to believe that it would be fixed in a future release but it wasn't. What I am referring to is IVF's failure to permit SEH in mixed C++/Fortran solutions. The same applies to C#/IVF Dll apps where C# can't handle Fortran exceptions (SEH could care less about the nature of the exception, FP or otherwise) that Fortran can't handle by design. This has been raised here in the past by others.

If you believe that IVF 11 can admit of SEH then post a sample so we can all see in action. I can't see why the C Interop feature would be hostile towards anything available to C.

BTW, has the IEEE FP feature been fixed? Yes, it was and may still be busted.
Gerry, please provide a test case that demonstrates the problem you describe. I can't puzzle it out from your description.

0 Kudos
Steven_L_Intel1
Employee
967 Views
As far as I know, Fortran does not prevent SEH exceptions from propogating through a Fortran frame. It is true that Fortran library-generated errors such as I/O errors and array bounds errors are not signalled as exceptions and cannot be "caught". I have a feature request in on that.

I tried the provided GETEPTRS example with 11.0.074 and it works.

I am unaware of any issues related to the IEEE FP modules. What problem do you see?
0 Kudos
gfthomas8
Novice
967 Views
As far as I know, Fortran does not prevent SEH exceptions from propogating through a Fortran frame. It is true that Fortran library-generated errors such as I/O errors and array bounds errors are not signalled as exceptions and cannot be "caught". I have a feature request in on that.

I tried the provided GETEPTRS example with 11.0.074 and it works.

I am unaware of any issues related to the IEEE FP modules. What problem do you see?

I/O and array bound errors are just two ofmany exceptions that are catachable (sic)by SEH. However, IVF frustrates its ability to do so. It is the expectation of any serious developer on Windows to have full access to SEH no matter where an exception is raised. This is not a feature, its a given, an inalienable righton Windows and IVF shouldn't usurp it.

GETPTRS does not use SEH. On Windows, FP exceptions are the least of your worries: I/O and array bound violations for example.

If you are unaware of there being any problems with IEEE then it's probably still busted.
0 Kudos
Steven_L_Intel1
Employee
967 Views
Gerry,

I can find no problem reports in our database related to the IEEE FP modules. If you know of a problem, please provide the details and we'll be glad to investigate.

As for SEH, as far as I know, IVF does not interfere with it. Again, if you have a test case that shows otherwise, please provide it.
0 Kudos
gfthomas8
Novice
967 Views
Gerry,

I can find no problem reports in our database related to the IEEE FP modules. If you know of a problem, please provide the details and we'll be glad to investigate.

As for SEH, as far as I know, IVF does not interfere with it. Again, if you have a test case that shows otherwise, please provide it.

I know thatit doesinterfer and has done so since mid 9.1. Try to catch an IVF generated array bound violation or IO error with SEH, yourself. I can't and neither can you. It is noteworthythat the SEH samples that are part of CVF (where SEH is not undermined) are absent fromIVF, for obvious reasons.

As for IEEE, I really don't care whether it works or not, it's an abomination. If unimpeded SEH were available in IVF the IEEEfeature would berendered redundant. Was it subject to rudimentary QA?
0 Kudos
Steven_L_Intel1
Employee
967 Views
Gerry, you are quick to make vague accusations but not so quick to provide substantiation.

As I have noted, errors such as array bound violations are not currently signalled as exceptions so they cannot be caught. Which SEH sample from CVF do you refer to? Their absence from IVF is simply that I haven't gotten around to it yet, not anything nefarious. I tried the WINEXCP1 sample in IVF 11 and it seemed to work ok for the exceptions that got generated.

The IEEE FP modules are part of the Fortran standard. They are designed to be usable across different implementations. Fortran does not have any concept of SEH, so while you may find the IEEE modules difficult to use, they do work and have been tested.
0 Kudos
Reply