common/loop/severe 408

[alexkar]

Hi,

I tried to run a program in visual studio 2010 and got "forrtl: severe (408): fort: (2): Subscript #2 of the array Q has value 5164108 which is greater than the upper bound of 51"

The same code runs in visual fortran 6 without any issue.

What happened here was that within a loop a call in subroutine which calls another one with the same index. A pseudo-code that explains my problem is:

------------------------------------
program main
integer n,m,l,time,c
parameter (n=756,l=100,m=100,time=10,c=1)
double precision q(m+time,51,c),x(n),mm1,mm2,...
integer loc_id(n)
common /design/x
common /loc_id/loc_id
common /use/u
...
do j=1,c
do i=2,51
index=2
if (index.eq.2) then
do id=1,time
qt(1:m+id-1)=q(1:m+id-1,i,j) !888
tempo0=q(id+m,i-1,j)
qt(id+m)=tempo0
qt(id+m:m+time)=q(id+m:m+time,i-1,j)
call subr1(tempo0,mm2,id)
call subr2(tempo1,mm1,id)
if ((mm1-mm2).ge.1) v2=1.d+0
if ((mm1-mm2).lt.-10) v2=0.d+0
if ((mm1-mm2).lt.1 .and. (mm1-mm2).gt.-10) v2=min(1.d+0,exp(mm1-mm2))
unif=g05daf(0.d+0,1.d+0)
if (unif.le.v2) then
tempo0=tempo1
endif
! Copy the value into q
q(id+m,i,j)=tempo0 !here produces the problem. and if I comment this line then the error goes to 888
enddo
endif
enddo
enddo
...
end program main
===============
subroutine subr1(x1,y1,id)
...........
double precision x1,y1,y2,re,.......
common /design/x
common /loc_id/loc_id
common /use/u

y1=0.d+0
do i=1,n
re=x1 + u(loc_id(i)) + x(i)
call subr2(y2,re,i)
y1=y1+y2
enddo

end subroutine subr1
===============
subroutine subr2(y1,re,id)
...
double precision x(n),...,lgmval2
integer ifail,....
common /id/i
common /design/x
common /use/u

val2=...
ifail=0
lgmval2=s14abf(val2,ifail)
y1=exp(re+...+lgmval2)

end subroutine subr2
------------------------------------------------


So by seeing the loop index id in the main program after some iterations it became huge and caused this error. But directly it jumped from 4 (i=1, id=4) to 5163108.
...and there are no calculations with the indexes meaning something like i+j...

The index id does not change when running in visual fortran 6 and I don't get this error. (i.e. for all i's it goes from 1 to 10 always)

So is it the common statement the cause? (removing it just changed the number in the error)
or the use of the same index (changing it caused similar error due to the common statement in another part of the program)?
or?????????????? any hints how to solve it?
Plus, how come it runs without an error and without changing the loop index in the old compiler and not the new?

Best,
Alex

subroutine t_error(x1,y1,id)

[Steven_L_Intel1]

The problem with posting pseudocode is that it often hides what the real code is doing. The code you posted does not compile (ignoring the ... issue) and when the errors are fixed, runs without an error, so it is probably not close enough to what your real program does.

Can you attach either your real application or cut it down enough to still show the error?

There are many possible things that could cause errors to be detected when run in the newer compiler. The error you got suggests that you are referencing uninitialized storage, but until I can see real code that reproduces the problem, it's not much use guessing further.

[mecej4]

> The same code runs in visual fortran 6 without any issue.

Probably because subscript-checking was not requested. Not seeing any "issue" is not proof of there being no issues. After all, a program that does no output and runs to completion could be misjudged to have run correctly, no matter what it did.

> A pseudo-code that explains my problem is

For me, at least, you pseudo-code explained nothing. As Dr. Fortran has said repeatedly, we need to have code that can be compiled and run at this end to see the problems that you describe. Very often, I'd rather run the problematic code first before reading the explanation, so that I can better sense whether the proposed explanation may be leading me down the wrong fork in the road.

Please provide working code that is just enough to display the problem.

[alexkar]

Hi and thanks for the answers the actual code is 2000 lines so impossible to paste it all and forbidden to upload/give it (can't do sth for that, sorry)

so I copied the part that produces the error. It is edited above.

The output is written in files, before the end of the loop (for i) in the main program. To be processed by other programs.... Additionally, since this code was used for many years I compared it with standard statistical software (with functions not implemented by me) and the results were similar (in the 3digit difference which could be explained by the random number generator)

Firstly, I commented the line as mentioned on the code and then the error 408... went to where I have the comment 888. By inserting a print after the second call of subr1 "print*, 'index=', i" I saw the change in the i=4 loop. Exactly the same in visual fortran 6 keeps printing the correct index.

Then, I activated the check for uninitialized variables and it produced that in the subr2 the lgmval2 is not initialized.
I replaced lgmval2=1.d+0 and then the error went to mm2 in the main program also not initialized.
But this error occured after the 4th iteration again....

[mecej4]

> so I copied the part that produces the error

At that point we part ways. You have made a judgement as to which part is culpable, and you are showing me only that part. Even if your judgement is correct I cannot agree with it because the necessary context is missing.

If you create a reproducer and it is too long to paste inline, you may upload a copy and attach that copy to your response, as detailed in

Attaching files to a post

That you found some uninitialized variables indicates the possibility that similar bugs are more pervasive in your entire program. The compiler is unlikely to detect all instances of uninitialized variables.

[alexkar]

I totaly respect that.

I wrote a small code that runs and writes correctly in visual fortran 6 but although compiles and builds in the new one it produces nothing... you will need to change the pathname...
I don't know if it is the same issue or not since it produces no error but could be...
Perhaps there is a change in the common statements which I am not aware of.. 90's.........


[bash] program TEST integer n,m,l parameter (n=100,m=100,month=10,an=m+month,t=50) double precision unif, q(an,t+1), mm1, mm2,x(n),qt(an), u(n), tempo0, tempo1 integer loc_id(n) character*160 pathname common /id/i common /locs/loc_id common /design/x common /used/u external s14abf pathname='.......' open(51,file=trim(pathname)//'ids_test.txt') do i=1,n loc_id(i)=i x(i)=g05ddf(0.d+0,1.d+0) enddo do i=1,m u(i)=g05ddf(0.d+0,1.d+0) enddo q(1:an,1)=0.d+0 do i=2,t+1 do id=1,month qt(1:m+id-1)=q(1:m+id-1,i) tempo0=q(id+m,i-1) tempo1=tempo0-0.01 call subr1(tempo0, mm1, id) call subr1(tempo1, mm1, id) print*, 'i index=', i if ((mm1-mm2).ge.300) v2=1.d+0 if ((mm1-mm2).lt.300) v2=min(1.d+0,exp(mm1-mm2)) unif=g05daf(0.d+0,1.d+0) if (unif.le.v2) then tempo0=tempo1 endif q(id+m,i)=tempo0 enddo write(51,123) i 123 format(1(I55),118(I55)) enddo end program TEST !------------------------------ subroutine subr1(in, out, id) integer n,m,l parameter (n=100,m=100,month=10,an=m+month,t=50) integer loc_id(n) double precision in, out,out2, u(n), re, x(n) common /used/u common /design/x common /locs/loc_id out=0.d+0 do i=1,n re=in+u(loc_id(i))+x(i) call subr2(re, out2, i) out=out+out2 enddo end subroutine subr1 !------------------------------ subroutine subr2(in, out, id) integer n,m,l,ifail parameter (n=100,m=100,month=10,an=m+month,t=50) double precision in, out,val2, u(n), lgmval2 integer loc_id(n) common /used/u common /design/x common /id/i common /locs/loc_id val2=5.55 ifail=0 lgmval2=s14abf(val2,ifail) out=exp(in+lgmval2) end subroutine subr2[/bash]

[mecej4]

There are a number of variables that are implicitly given incorrect types in the short example of #5. Rather than listing them, I ask that you add IMPLICIT NONE to each of the three program units, and get the compiler to help you to add suitable declarations.

Note also that mm2 is used but its value is never set. Probably, the second call to subr1 should contain mm2 as an argument rather than mm1.

Having added the missing declarations, I found that CVF66 and IFort 12.1 produced the same output file. This, however, is almost worthless since the files just contain values of the DO loop index.

Note that the g05d?f routines used are obsolete and need to be replaced by newer calls if you want to use a current version of the NAG library.

As noted in #4, if your larger code contains errors with a density (bugs/line of code) similar to that in the example, you can look forward to setting aside a considerable amount of time to tracking down and fixing the bugs.

It may be useful for you to read the article Migrating From Compaq Visual Fortran . See also the User Note for the NAG library that you are using to make sure that you are following the proper calling conventions for the NAG routines.

[Les_Neilson]

Hi
It does sound very much likeuninitialised variable(s) and/or array bounds errors.

In addition to what others have said, one possible way to help isolate the problem is as follows.
Copy the whole project to a work area.
(note also : 2000 lines is not particularly big - but it is preferablethat code should be *attached* to a post and not pasted into the post. Better still if you can attacha whole solution/proj files)

You know where the error occurs so anything *after* that can be removed from the (copied) code. This way youshould be able toreduce the problem to a more manageable size. Gradually remove sections of code for as long as the problem persists.
It is reccommended that you put "implicit none" throughout your code, compile with all the check options swithed on, and switch on runtime options especially to check array bounds and uninitialised variables.
If that hasn't helped you to identify the error then once you get a reduced program which still reproduces the problem it may be possible that you could post that here. As long as we are able to compile/build/run the code you stand a better chance of someone being able to help.

Les