Why can't I debug the START of a DO LOOP?

[billsinclaol_com]

In this example, I want to set a breakpoint at the DO statement:


Do I=1,100
Etc.
Etc.
End do

But it takes a breakpoint 100 times no matter what I do,
even when the little dot is ON the Do statement.
I didNOT want the break to be on the statement after the Do statement.
So I put a CONTINUE statement BEFORE the Do loop, and
it will NOT set the breakpoint there. It wants to jump ahead.

I thought we didn't have to put JUNK statements in to get it to break
where we want it?

Is that asking too much?

[WSinc]

Hi -

that LOC2= statement was an artifact left over from when I had an argument in the
call sequence. So it is a BUG which not trigger a BP on my end. You can comment that out.

I was wondering if my Parameter statements could be behind this.
That upper limit is derived from the product of two other parameters,
which should be 36. (6*6 = 36)

For some reason, the security analysis doesn't evaluate the expression NRP*NCP which is 6*6 = 36.
That sets the upper limit of many DO LOOPS all throughout the code.

Take a look at the "params.inc" file which has that expression in it.
Could the order of the INCLUDES have an effect?

If you tell me how to run the "security analysis" tool, I can run it on my end.

R U running Windows 7 on your end?

Yours; Bill

[Steven_L_Intel1]

You need to have Parallel Studio XE or the new Fortran Studio XE suites installed in order to run the Static Security Analysis. SSA might not get everything right - I omitted a couple of its complaints that were inappropriate (but I understand why they were there.) I would not focus on the array bounds issues so much as the uninitialized variables. The order of includes should not matter.

I am running Windows 7.

[WSinc]

Hi -
I ran a little experiment.

Apparently the compiler expects the PARAMETER evaluations to be in a definite order.
For example if you say

PARAMETER C=A*B
and then
PARAMETER A=10, B=15
it won't compile, but if you put them in another order, it will.

So it appears that the PARAMETER evaluation has to be in a definite order.
This is perhaps why the INCLUDES might have to be in a special order.

[Steven_L_Intel1]

"won't compile"? What is the error? The order of PARAMETER statements should not matter unless you are referencing a PARAMETER in the value that is defined later.

[WSinc]

Example:

The first subroutine doesNOT compile,
but the second one does. Is this what you meant?

subroutine test1()

Parameter C=A*B

Parameter A=10

Parameter B=20

end

subroutine test2()

Parameter A=10

Parameter B=20

Parameter C=A*B

end

[Steven_L_Intel1]

Yes, that's what I meant. It's not what you showed earlier.