- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
While in the debugger and steppingthrough code using the F10 key I noticed that execution appears to jump from the firstIF() encounteredto an unrelated IF() some distance into the routine. When F10 is pressed again execution appears to jump back to the first IF(). The only thing in common appears to be the PARAMETER Epsilon. Is this normal behavior, and if so why? Thanks for any info.
INTEGER, NumSigValues
REAL POD, Sigma
REAL, DIMENSION(6) :: NVSig
REAL, PARAMETER :: Epsilon = 0.000001
!!! JUMPS FROM HERE TO IF() BELOW
if(ABS(POD - 1.0) .LE. POD*Epsilon) then
POD = 1.0
else if(ABS(POD-1.24) .LE. POD*Epsilon) then
POD = 1.24
else if(ABS(POD-1.50) .LE. POD*Epsilon) then
POD = 1.50
end if
....
....
do i = 1, NumSigValues
!!!! JUMPS TO HERE THEN BACK TO FIRST IF()
if(ABS(Sigma-NVSig(i)) .LE. Sigma*Epsilon) then
Sigma = NVsig(i)
! exit do loop
exit
end if
end do
Link Copied
- 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
Optimization setting was DISABLE in Properties for Debug. I also noticed that when Epsilon was changed from a variable in the expression to an actual value the jumping did not occur.
! NO JUMPING OCCURS USING 0.000001 RATHER THAN EPSILON
if(ABS(POD - 1.0) .LE. POD*0.000001) then
POD = 1.0
else if(ABS(POD-1.24) .LE. POD*0.000001) then
POD = 1.24
else if(ABS(POD-1.50) .LE. POD*0.000001) then
POD = 1.50
end if
- 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
Are you using a slightly-older compiler? I think the current version is 9.1.034 (Steve will correct me if I'm wrong ... )
There was a problem a while ago where PARAMETERS of type REAL did, in fact, cause this kind of crazy line-stepping behavior. Any reference to the PARAMETER was "stuck" on the line number of either its declaration or its first appearance in the code.
If you are using a newer compiler and still getting the problem, please submit an example program through the support channel. It would be nice to get 'em all squashed.
thanks -
- Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could not find a compiler setting /debug-parameters. Looked on the property sheet and in IVF reference manuals but found only /debug:[keywords] and no keyword for parameters.
I am using IVF version 8.1....so that may be the problem.
I have a lot of REAL, PARAMETERs in other routines, and have not noticed this line-stepping behavior before. However, mayhavedebugged these routines with CVF and not IVF, not sure.If this is the problem, I assume it isminor and that it only affects the debuugger.
Thankyou for the replies.
- 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
Steve,
Is this strictly a debugging problem, orshould the code be executing properly?
I'm experiencing this same problem with a legacy Fortran code I've converted to a DLL and call from C++.My legacy code worked fine as a DLL under CVF 6.6B, butfails underboth IVF 8.1.042and IVF 9.1.033 (I use .NET 2003, which apparently has a problem with 9.1.034, according to the distro notes). I checked for the new debug-parameters (Fortran|Debugging|"Information for PARAMETER Constants", right?)and it is "None", although I don't think that's the problem anyway, as I'm not using the PARAMETER attribute.
I've been having a devil of a time trying to debug this 80K+ LOC DLL with the jumping around. And an even harder time whittling it down toa test caseI can submit through Premier support that behaves the same way (I use an external cross-platform C++ library).
-Dan Hoyt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is just a debugging issue, it does not affect execution correctness.
The problem with 9.1.034 is just a debugger integration problem - either you can debug or you can't.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It turns out part of my debugging problem is due to optimizations, after all. My legacy code uses the /fast option, which sets /O3 in the background. When IVF converted my CVF projects, it removed the /fast option, so I added it back in. AfterI removed /fast (again), myexecution lines match the source in the debugger!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not recommend using /fast - it has other side effects you may not want, such as requiring certain Intel processors, and the set of options can change between releases. I think it was /Qipo that did you in. Look in the documentation to see what /fast does and then pick the options you want from the set. /fast is less useful in ifort than it was in the DEC/Compaq compilers.
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/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