Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28446 Discussions

storage extent of the dummy argument exceeds that of the actual argument

Mike896
Beginner
2,105 Views

Hi

I have a package of old *.for files. They are compiled and linked ok when using CVF.

However, if I compiled them in IVF, there are errors:

error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [UU]

error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [AA]

How to solve this problem?

Mike

0 Kudos
10 Replies
TimP
Honored Contributor III
2,105 Views
Quoting - Mike896

error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [AA]

CVF likely would have told you about this if you built with /debug, or put all the sources in one file. It would not make your program run incorrectly, as long as the subroutine doesn't use data beyond the extent of the actual argument. In fact, if you are using it like an assumed-size array (dimension(*)), the compiler generated code might be the same, and you could turn off the checking, as you did in CVF. If you want to correct the code and make it f77 compatible, assumed-size, or explicit variable bound, are your choices. Module or internal (CONTAINS) subroutines are the most often recommended choices.

0 Kudos
Steven_L_Intel1
Employee
2,105 Views

Actually, I don't think CVF would have detected this error - it's something we added after CVF.

What this means is that you have declared a dummy argument in a routine to be larger than the actual argument passed. For example:

[cpp]real a(10)
call sub(a)
...
subroutine sub(a)
real a(100) ! Error![/cpp]

The fix is to correct the declaration of the dummy argument. You might want to make the size match, you may want to use (*) for assumed-size or you may have passed the size in as another argument and then declare the argument as an "adjustable" array (N).

0 Kudos
Lee1
Beginner
2,105 Views

Actually, I don't think CVF would have detected this error - it's something we added after CVF.

What this means is that you have declared a dummy argument in a routine to be larger than the actual argument passed. For example:

[cpp]real a(10)
call sub(a)
...
subroutine sub(a)
real a(100) ! Error![/cpp]

The fix is to correct the declaration of the dummy argument. You might want to make the size match, you may want to use (*) for assumed-size or you may have passed the size in as another argument and then declare the argument as an "adjustable" array (N).


I am also getting the following error message when compiling a program with IVF that was initially developed with CVF:

"error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [XO]"

The following lines appear in the main code:

integer, parameter :: dbl=8
real(kind=dbl) XO(7,2001)
.
.
call CALCBIOMASS(XO,XN,rX,n,dt,XMAX)

And the following lines appear in the subroutine:

subroutine CALCBIOMASS(XO,XN,rX,n,dt,XMAX)
integer, parameter :: dbl=8
real(kind=dbl) XO(7,2001), XN(7,2001), rX(7,2001), XMAX,dt, xres(7,2001), xtmp(7), xntot(2001)

It's seems that I have declared the dummy argument in the subroutine (XO) to be the same size as the actual argument passed. Thanks for any help!
0 Kudos
Steven_L_Intel1
Employee
2,105 Views
I can't reproduce the problem based on this snippet. My guess is that your actual code is somewhat different. Can you come up with a small but complete test case that shows the problem?
0 Kudos
Lee1
Beginner
2,105 Views
I can't reproduce the problem based on this snippet. My guess is that your actual code is somewhat different. Can you come up with a small but complete test case that shows the problem?

Here's a test case -- pardon my ignorance:

program test2
!
implicit none
integer, parameter :: sng=4
integer, parameter :: dbl=8
!
real(kind=dbl) XO(2,10)
integer i,j
!
do 10 i=1,2
do 20 j=1,10
XO(i,j)=6
20continue
10 continue
!
! Calculate new biomass concentrations
call CALCBIOMASS(XO)
!
end program test2
!
! ***********************************************************
subroutine CALCBIOMASS(XO)
!
integer, parameter :: dbl=8
real(kind=dbl) XO(2,10)
integer i,j
!
do 100 j=1,10
do 110 i=1,2
XO(i,j)=XO(i,j)+6
110 continue
100 continue
!
end
!
0 Kudos
Peter
Beginner
2,105 Views
Lee,

Are you getting the same error messages, when you debug the above code (previous thread) ??

I do not see any error messages when I try to run this code, i get the output as
12 12 12 12 ...........
a 2-by-10 matrix.

Why don't you try using 'dimension' if it is feasible??

What compiler are you using??
0 Kudos
Steven_L_Intel1
Employee
2,105 Views
Try this. Delete any .mod files in the output directory and compile again. You probably have generated interface checking on (it's on by default in 10.x) and this can sometimes get confused if you changed code without doing a revbuild.
0 Kudos
Peter
Beginner
2,105 Views
Try this. Delete any .mod files in the output directory and compile again. You probably have generated interface checking on (it's on by default in 10.x) and this can sometimes get confused if you changed code without doing a revbuild.

Steve,

Are you talking about 'Check routine interfaces'(in properties>fortran>diagnostics), I have (fortran 11.0) it as Yes(/warn:interfaces). It means its turned on.

But I still can successfully run the code that Lee has presented !
0 Kudos
Lee1
Beginner
2,105 Views
Try this. Delete any .mod files in the output directory and compile again. You probably have generated interface checking on (it's on by default in 10.x) and this can sometimes get confused if you changed code without doing a revbuild.

That seems to do the trick. Thanks!!
0 Kudos
Steven_L_Intel1
Employee
2,105 Views
Thought it might. This is a design problem with the generated interface checking in that it does not recognize when a generated module has become stale.
0 Kudos
Reply