- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page