Do-continue loop issue

[this_is_mine]

Some old code issues. I have tried replacing the loop with a DO-END DO loop, did not solve the problem.

Do loop does not seem to be exiting properly

Example:

Do 700 Niter=1,Noiter
***
Code
***
700 Continue

In debugger, Noiter is equal to 2, a watch shows that Niter will increment greater than Noiter until loop is exited be some other means. Niter and Noiter are not changed in the loop, this has been shown by stepping through each line with a watch on Niter and Noiter, they do not change. Both variables are integers.

Other do loops in the program run fine, tried hard coding a number for Noiter, problem remained.

[Steven_L_Intel1]

The compiler may not be using the variable to test the end condition, it may have computed a trip count instead (the standard allows this.) It's impossible to tell anything from a paraphrase of a snippet of code. If you can come up with a standalone reproducible example, feel free to report it to the compiler vendor's support team (I don't know what compiler you are using.)

I have seen cases where mismatches in arguments for routines called in the loop can cause corruption of variables (or temporaries) in the caller. The best way to debug this is to step through the instructions to see what is being actually tested to exit the loop.

[this_is_mine]

Using Compaq Visual Fortran Pro. 6.5.0

This is some old code which has been compiled and used many times before. This si the first time this problem has been noticed.

I tried replacing the variables with new variables that I know will not be changed elsewhere in the code. Unfortunately I cannot supply the code. There is a lot of it and is fairly proprietary.

this is and example of the change I have attempted:

NoiterJIM = Noiter

Do 700 NiterJim = 1, NoiterJIM
Niter = NiterJIM
! Several functions and procedures are called
! Some involve passingg Niter, but cannot find it
! being changed.
700 continue

This did not solve the issue

unfortunately (or maybe fortunatley) I am not a programmer by trade, but even though I deal with it quite regularily, there is a lot i don't understand. Several people around the office have looked at this and we are all stummped. the only solution thus far has been to say "if (Niter.gt.Noiter) goto 701" we do not wish to use this method in case the issue exists elsewhere.

[Steven_L_Intel1]

First thing to try is upgrade to 6.6 and then 6.6B or C.

Second, try commenting out the function calls, in turn, to see if one of them affects the behavior. I would guess that it is a function call that is corrupting storage, such as array references or mismatched argument declarations. Another thing is that if you call a non-Fortran routine, make sure that the calling mechanism (STDCALL vs. C) matches, otherwise you can get symptoms such as this.

[this_is_mine]

The fight continues..

Apparently this program was previously compiled on version 5.0 and worked properly, this was before my time here. Our computer guys are looking into if we have the pro version of 6.6. I also tried 6.1 and obtained the same results I am getting now.

We were looking into the possibility of the increment counter or the max value of the DO loop being corrupted by one of the fucntions being called. We used a watch in the debugger to monitor the values of Noiter an Niter before and after each function call. Everything seems normal, the values do not change except for the expected increment of Niter. For example:

N = 3
do 700 i = 1,N
call function(...)
700 continue

the watch on N always shows 2.
the watch on i goes 1, 2, 3
at line 700 after the third loop N=3, i=3 the next step goes to the call of the function with N=3, i=4.

It is expected that if the values become corrupt, that this should be apparent in the watch, should it not?

Thank you for all your help, it is greatly appreciated.

[this_is_mine]

6.6B did not solve the issue

[this_is_mine]

I just used 5.0 on an old computer to run the exact same code that is giving us issues and everything worked fine. Are there any known issues with this in 6.6B?

[Steven_L_Intel1]

Watching the variables in the debugger may not help - the compiler may not be using the variables. To know for sure, one has to step through the instructions and look at the instruction that tests for the exit condition to see what it is using. If I were debugging this, I would also watch the value of the ESP register (stack pointer) across the routine calls to make sure it was restored properly after each call.

[Jugoslav_Dujic]

I posted a "stack checker" routine recently here.

I'm pretty sure the problem is in your code,but it's obviously a tricky one.

The cause (I'd place my bet on it rather than on stack corruption)might be as well a silent array bounds violation. Note that CVF does not check the array bounds on assumed-size dummy arrays. If I'm right, the easiest way to find out is to:

1) Enclose all called functions in MODULE(s)

2) Replace all assumed-size dummy arrays (*) or (1) with assumed-shape arrays (:)

3)Use the module from the caller

4) Debug. An "Array bounds exceeded" will occur within a routine if I'm right.

Jugoslav