Error #6634

[mbehzad]

Hi,

I am going to compile a Fortran 77 code on win 64-bit. During thebuildingI got the following error which I don,t have on the win 32-bit;

error #6634: The shape matching rules of actual arguments and dummy arguments have been violated

I think this is not the code problem, since I compiled in on 32-bit machine without any issue.

I am wondering if some body could help me on this issue.

[Steven_L_Intel1]

It is almost certainly a code problem - I can think of lots of bad code that will work on 32-bit systems but fail to compile on 64-bit systems. In addition, you may be using a different compiler or different options. My guess is that the default enabling of generated interface checking in new Visual Studio projects is causing this error to be detected where it wasn't on your 32-bit system.

Please show the call in question, the declarations of all of its arguments, and the "header" of the routine being called including all the arguments and their declarations.

[mbehzad]

Quoting - mbehzad

Hi Steve,

here is the function and where it is called in the main program. All data are declared implicitly in double precision.

this is the function subprogram;

implicit double precision (a-h,o-z)

function loci (ia,iz,nbytei)

num=loc(iz)-loc(ia)+nbytei

loci=num/nbytei

if(nbytei*loci.eq.num) return

write( *,10) nbytei,loci,num

call exita(88)

entry locr (a,z,nbyter)

num=loc(z)-loc(a)+nbyter

locr=num/nbyter

if(nbyter*locr.eq.num) return

write( *,20) nbyter,locr,num

call exita(88)

end

and this is where it's called;

ncom1=locr(aaa1,zzz1,nbyter)

do 10 n=1,ncom1

10 aaa1(n)=0.0

How can I deactivate the generated interface checking?

thanks

Mohsen

[Steven_L_Intel1]

You didn't show the declaration of the arguments but you did show that aaa1 is used as an array and you are passing it to an argument that is a scalar. You're using a classic trick to get offsets into arrays that is not legal Fortran but it works if the compiler doesn't catch you.

The simplest fix is to pass aaa1(1) (and perhaps zzz1(1) if it is also an array). That will be legal and will do what you want. If you really want to run with the blade guard removed, set the project property Fortran > Diagnostics > Check routine interfaces to No. I do not recommend this.

[mbehzad]

Quoting - mbehzad

Thank you Steve, It works.

But I have the similar problem with data type which is indicated by the classical error #6633 as follows,

"The type of actual component differs from the type of the dummy argument" forvariabletstart.

I check thesubroutineand the mainprogramand in both of them the data type are double precision; here is thesubroutineand where it is called in main program. Again the data type was implicitly declared in the main program.

subroutine second (tnow)

double precision tnow

real*4 d(2)

rtnow=etime(d)

tnow=d(1)+d(2)

return

end

main program;

implicit double precision (a-h,o-z)

call second(tstart)

Again, thiscommercial code is compiledon the win 32-bit without any problem.

thanks,

mohsen

[Steven_L_Intel1]

Forum hint - when entering a reply, position your cursor outside the gray "quote" box.

I hate seeing IMPLICIT but what you've posted looks ok. Try doing a Build > Clean Solution followed by a rebuild of the project and see if the error goes away.

[mbehzad]

Quoting - mbehzad

Hi,

I am going to compile a Fortran 77 code on win 64-bit. During thebuildingI got the following error which I don,t have on the win 32-bit;

error #6634: The shape matching rules of actual arguments and dummy arguments have been violated

I think this is not the code problem, since I compiled in on 32-bit machine without any issue.

I am wondering if some body could help me on this issue.

Hi Steve,

thank you for yourpatience,

It works. But I did the same thing except that after clean solution, instead of using rebuild I used build, and the problem still existed. But now it works.

The objects files were created but some other errors appeared. It seems that they arerelatedto linking the object files. as the error said; "error LNK2005: EXITk already defined in k3prep.obj (one of the source file)" for the kiva3.obj (the other source file). EXITK is asubroutinethat was defined in both source files.

I thank you in advance.

mohsen

[Steven_L_Intel1]

I'm glad to hear it. I assume you figured out that you can have only one EXITK routine in the program. Do you need further help at this time?