shape matching between dummy and actual

[Tai_Q_]

Now I am debugging a FORTRAN code written many years ago. It was written in *.f.

The following is just a demonstration of the original code.

program main
implicit none

integer,parameter::n=2

integer a(n)
call initial(a)
end program main

subroutine initial(a)
implicit none
integer a(*)
a(1)=1
a(2)=2
return
endsubroutine

So what should I do to correct the original code? The only way is just send the dimension of the array to the subroutine?

[Steven_L_Intel1 · Accepted solution]

There's nothing wrong with the code you posted, Please show the real code. We only need to see the declaration section of the caller and subroutine, and the call statement. Your actual code is something different.

[mecej4]

It is not clear what the real problem is; the code example has no problems. If more flexibility is needed, the working size of the array a() can be passed as an additional argument, or made available through a module.

Please explain the issue or give a better example that shows up the problem.

[Tai_Q_]

Hi Steve,

In fact, the code I have posted can not get passed in my compiler.

Error    1     error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.     

The above error is for the line " call initial(a) ".

Here is the real code

.....

complex coef(ldr2,ldr2)

dimension narray(2)

call fourn(coef,narray,2,-1)

......

subroutine fourn(data1,nn,ndim,isign)

dimension nn(ndim),data1(*)      !Even if I changed it into "complex data1(*)", the same error occurred.

...

endsubroutine

The error occurred in the line "call fourn(coef,narray,2,-1)". 

Error    1     error #6633: The type of the actual argument differs from the type of the dummy argument.   [COEF]    

Thank you!

Tai

[mecej4]

The type mismatch is not just in the types of the array elements of COEF and DATA1, but from their ranks. In the caller, COEF is a two-dimensional array of type COMPLEX. In the subroutine, it is a one-dimensional array of type REAL (by default implicit typing, a variable starting with D is real). Even when you declared DATA1 to be of type complex, the array rank mismatch persists. 

The following corrected version is acceptable to the compiler, but does nothing useful when run. Note that ISIGN is an intrinsic function (it may have been used more often in older codes), and so it is better to use a different name for that variable.

program broken

   implicit none
   integer, parameter :: ldr2 = 2
   complex coef(ldr2,ldr2)
   integer narray
   dimension narray(2)
   call fourn(coef,narray,2,-1)

end program

subroutine fourn(data1,nn,ndim,isign0)

   implicit none
   integer nn,ndim,isign0
   complex data1(ndim,ndim)
   dimension nn(ndim)

end subroutine

[JVanB]

You don't have to match ranks of arrays unless the dummy argument is assumed shape, pointer, or allocatable, or the invocation is through a generic name. The following compiles, so I don't see enough context to understand the error message. The specification part of subroutine initial would have been nice to see, too.

module m
contains
subroutine fourn(data1,nn,ndim,isign0)

   implicit none
   integer nn,ndim,isign0
   complex data1(*)
   dimension nn(ndim)

end subroutine
end module m

program broken
   use m
   implicit none
   integer, parameter :: ldr2 = 2
   complex coef(ldr2,ldr2)
   integer narray
   dimension narray(2)
   call fourn(coef,narray,2,-1)

end program

[Steven_L_Intel1]

Tai, the code you posted doesn't look anything like what the error message suggests. There is no M in the program you posted, there is no explicit interface and your example did not omit any arguments.

As for the error 6633, you have indeed mismatched the types. It was not uncommon in very old Fortran code to pass complex arguments to a subroutine that accepted them as arrays of reals. This has never been legal in Fortran, but many older compilers did not detect the error for calls to routines with implicit interfaces. The Intel compiler's "generated interface checking" feature does catch such errors and this is on by default in a Visual Studio project.

RO is correct that the ranks generally don't have to match, with the exceptions he notes.