Debugging Behaves Irratically

[kschmitt_dom]

I cannot seem to follow my code in any logical way using the Step In function with the debugger in Parallel Studios XE 2011 with VS2008. First, it jumps around irratically without setting any values (skipping input lines entirely) and then, once values begin to be set, it skips over select calls to modules or jumps several lines of code. I am not suggesting the debugger is behaving incorrectly - just differently from what I was used to with Compaq VF.

Is there some project option I can change to have the debugging behave in a more user-friendly manner?

(Sorry for the non-scientific explanation).

[mecej4]

Make sure that the source files that you wish to exercise in the debugger are compiled with optimizations turned off.

[kschmitt_dom]

Thank you, but this problem is occuring when I believe I have all optimization options disabled in the project. I.E., under Fortran => Optimization

Optimization -- Disable
Inline Function Expansion -- Disable
Interprocedural Optimization -- No

Are there any options that I might check to ensure optimzation is turned off for source files being debugged?

[IanH]

Sometimes, even in debug mode, the sequence of instructions executed by the chip don't correspond all that well to the order of Fortran statements. This happens in particular as procedures are being "set up" - as the program takes whatever actions are needed to implement the outcome of any specification statements (default initialisation of objects of derived type, setting allocatable variables to be unallocated, checking argument length matches, setting up automatic variables on the heap, clearing the sink of dirty dishes...) at the start of the procedure.

I've also seen it happen (though not recently) with some IO statements, where stepping over a read or write results in the debugger jumping to an open or close statement and then back again. I suspect (without having checked) this might be due to diagnostic or check code being emitted once by the compiler for a procedure and tagged with the first line that calls it, but then used by multiple statements in the procedure. These shared sequences of machine instructions can only be designated to have come from one particular statement (source code line actually) in the debug information for the procedure, so the debugger thinks your are jumping all over the show.

In the latter case the real execution sequence is still as per your code. In the former case, it doesn't matter - specification statements aren't executable, so there's no concept of execution order anyway.

Is this similar to what you are seeing?