\"Active DO-loop index altered\"

I get sometimes this hidden error and it takes a lot of scratching to find this specific index which is in violation. Is it possible to make it clearly named in SDBG showing exactly which index and in which subroutines are altered ?

Like today for example...In some circumstances some chain of subroutines with a lot of stuff inside alter something in other ones which call them. 5am at the morning and i am still not there... :x . The debugger stopped on 'call temporary_yield@()' line an is silent like catched war partisan 😃. That probably means that actual violation happened long ago and became exposed just when temporary_yield@ was called....such a damn nasty bug... This bug (and another which may change the color of the plotted curve) lives in this code for a long time....10 years probably...will try tomorrow, it annoys me too much lately.

Tried to make a small prototype which reproduces this bug but failed and also got even more questions. Failed because the way i suspected this error occurred does not work at all (see below). And the question is following: is this way of changing the main loop index legitimate?

        common i
        do i=1,10
        call subr
        enddo
        end
       
        subroutine subr
        common i
        i=100
        j=1000
        k=10000
        end

This code works with no complaints! I have nothing against of it, and even like it, but is this standard conforming? And now i am even more confused. How my specific error was generated by the compiler?

You need to compile this with /check to get a runtime failure.

Dan,

I've had problems with this bug, as in one case it took some time (years) to find the source of the error, when the do index is in common. I've since tried to remove this structure or at least ensure that do indexes are only 'intent (in)' if used in a subroutine call. A possible bug to be avoided.

John

You're right Paul i forgot /check so this example above is the right example to demonstrate what i think is missing in debugger

I am trying to say that the debugger does not tell explicitly that index i has been changed inside subroutine. Though which index is used in this simple is obvious, but in large code with the chain of spaghetti code and subroutines it is hard to find what and where anything was changed by index coincidence. Specifically because the fact that index will be changed inside some subroutine will be exposed to user much later the moment it was actually changed

So far my kazak attack fails.... i can not find any indexes violated in my own large code subroutine where code stopped coinciding to one in calling it program....Nor in other subroutines called before. The code aborted by the way not on exit from the subroutine like in example above, but on some intermediate sentence inside subroutine which has nothing incriminating in it.

I hope this can be programmed to show indexes explicitly in debugger and this difficult type error will be gone forever.