Cannot debug large program in 11.1 065 x64

[gfellaqmulacuk]

Hi,

I am trying to debug a large programme with the above version of Fortran.

I can up to the point where the programme calls a subroutine using a large number of large matrices. Attempting to step into the subroutine produces no result. If instead I position myself or set a breakpoint inside the subroutine in question and start debugging the yellow arrow never appears next to the breakpoint. When the programme reaches the point the Watch window displays "Unable to evaluate the expression" next to all the variables listed.

Is it a known bug? The programme runs fine both in debug and release mode.

TIA.

Giulio

[Steven_L_Intel1]

Unfortunately, your description is too general to be able to answer your question. Since it is a large program I suggest that you open an issue with Intel Premier Support and attach a ZIP of your project with everything needed to reproduce the problem. Before you do, though, I suggest you download and install Intel Visual Fortran Composer XE 2011 Update 2 (12.0.2) which is current. This includes debug fixes and may help you.

[jimdempseyatthecove · Accepted solution]

When the subroutine is compiled with optimizations enabled, and in particular if the optimization inlined the subroutine, then it may be difficult to follow a debugging session. Even in release mode you can select individual file optimization options that differ from the project setting for a given build configuration. Try turning off optimizations for this subroutine .AND. disable interprocedural optimizatons.

"Unable to evaluate the expression" usually means:

a) the call stack is not focused on the subroutine (you can double-click on different levels)
b) the file had the debug symbols stripped
c) the subroutine was inlined
d) the variables were optimized into registers.

Jim Dempsey

[gfellaqmulacuk]

Jim,

you were spot on. Turning off off interprocedural optimization did it. Thank you so much!

giulio

[mecej4]

> Is it a known bug?

No, in this instance, we are able to say, "It is a known feature" without keeping tongue-in-cheek.

As the optimization level is increased, the correlation between line number and instruction address becomes weaker. If the compiler supports debugging optimized code at all, it can still be disconcerting to try to step to the next line on the screen facing you, and seeing the cursor jump backward, instead, to the beginning of the subroutine, or forward across many lines to the last statement of a DO loop.

If you are debugging code from an algorithmic viewpoint, and that code is not overrunning array bounds, nor reading uninitialized memory, etc., turning optimization is the best solution, as Jim advised you. There are times, however, when your code seems to be fine, runs fine with another compiler, or misbehaves only when optimization is turned on. These are hard cases because turning optimization off is not a viable option.