PARAMETER attribute and debugger

[gelarimer]

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

[Steven_L_Intel1]

The PARAMETER statement itself is not particularly relevant, but sometimes you can see this jumping if the compiler has moved code around. If you see a case such as this when optimization is disabled, please send a test case to Intel Premier Support so that it can be looked at. Perhaps we can get the compiler to be a bit "smarter" in how it assigns source lines to code.

[gelarimer]

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

[Steven_L_Intel1]

Did you enable /debug-parameters ? I could imagine that this might occur if you did.

[Lorri_M_Intel]

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

[gelarimer]

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.

[Steven_L_Intel1]

That option was new in 9.0 (and was not in the IDE until 9.1.)

[gelarimer]

Thanks for the info.

[danhoyt]

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

[Steven_L_Intel1]

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.

[danhoyt]

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!

[Steven_L_Intel1]

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.