error#6634

[Qaiser_Bozdar]

error#6634: the shape matching rules of actual arguments and dummy arguments have been violated. [SIGR] 

Kindly help me to kill this error. @Steve_Lionel

I am using MS Visual Studio 2022 (community version) and have the Intel FORTRAN compiler 2024.0.2. 

Overall, there is no coding and algorithmic error in my code, but it gives an error of type error#6634. I searched for solutions to this error in this community, but I was not able to understand anyone. SIGR is one of the variable of type REAL inside the parenthesis of the subroutine which I am branching using CALL. 

For Example:  REAL CALL Section(AAR, FBG, SIGR, PIME)

This error is related to the CALL statement. I think this error is related to any one of the variables in my subprogram call. I am doing a scientific computation. 

Please have a look at the following.

[andrew_4619]

So how is SIGR declared in the caller and how is the corresponding dummy arg in the subroutine declared. It says they don't shape match so show us the EXACT declarations. More likely you have a code bug that needs to be corrected. 

[Qaiser_Bozdar]

Thank you for reply and I respect your attention.

I cannot share the complete code but I will share How I declared SIGR, I declared SIGR in caller and in subroutine. 

Part of my actual FORTRAN CODE:

REAL SIGMAS(200,5,5),SIGMAA(200,5), NEWSIGMAF(200,5),SIGR(200,5)  !!! complex number

 CALL SECTION8(D,SIGMAA,NEWSIGMAF,SIGMAS,PPFLUX,XI,NZ,NG,NGT,NGD,SIGR,BSQ,NINP,NOUT) !!! Here is my SIGR in Call

REAL XI(5),D(200,5),PPFLUX(200, 5),SIGR(200,5),BSQ(200,5) !!! This is inside my subroutine 

WRITE(NOUT,104)IZ(JJ),IGP(JJ,J),D(IZ(JJ),J),SIGR(IZ(JJ),J)!!! out of subroutine

!!!!! Out of subroutine 

DO KKG=1,NG
SIGR(IZ(JJ),J)=SIGR(IZ(JJ),J)+SIGMAS(IZ(JJ),J,KKG)      
ENDDO

That's everything related to SIGR..... in my code

Highly excuses for late reply (Time zones are different)....

Thank you

[Ron_Green]

still not enough code.

Give us

subroutine section8d( ...dummy arguments...)

and the declarations for each dummy argument in section8d

[Qaiser_Bozdar]

@Ron_Green  

Here it is, the part you want. 

SUBROUTINE SECTION8(D,SIGMAA,NEWSIGMAF,SIGMAS,PPFLUX,XI,NZ,NG,NGT ,NGD,SIGE,BSQ,NINP,NOUT)

REAL SIGMAS(200,5,5),SIGMAA(200,5), NEWSIGMAF(200,5)

REAL XI(5),D(200,5),PPFLUX(200,5),SIGR(200,5),BSQ(200,5)

INTEGER IZ(300),IGP(100,6),N(200)

      DO I=1,10

       N(I)=I

    ENDDO

[mecej4 · Accepted solution]

The eleventh dummy argument is SIGE, and that variable has no type or dimension declaration. Under implicit rules, SIGE is a real scalar variable.

The corresponding actual argument, SIGR, is a two dimensional real array. The two (SIGE and SIGR) do not match.

Do you now see why the screenshot that you posted is next to useless?

[Qaiser_Bozdar]

Thank you @mecej4 . I have already fixed that issue with SIGR. I only replaced SIGE with SIGR. The error is no more. 

Thanks to @Ron_Green who directed me about subroutine section8( ...dummy arguments...). 

Now, my code is error free. But I have another problem. I am looking into it. A debug problem.

Background Story: The code, which on I am working, was DEVELOPED using Digital visual FORTRAN Professional Edition 5.0A compiler in 2011 in MS Visual Developer (1994-97). My task is to run that code in MS Visual Studio (2022) using Intel FORTRAN Compiler. I am using Intel FORTRAN Compiler 2024.1.0 (Latest). I have removed many errors especially related to the format of comments (!! ,***, C, c). The lower bound for an array was zero in that code, now compiler says the lower bound is 1. I have changed that and errors are removed. 

Thank you to all prestigious scientists and engineers.  

[jimdempseyatthecove]

>>I have already fixed that issue with SIGR. I only replaced SIGE with SIGR. The error is no more. 

Caution, that change may have made the error report go away...

... but indicates that either

a) The old code was in error

.OR.

b) Your change is in error.

You really need to look closer at the execution consequences of making that change.

Check the old code of this subroutine to see if SIGE is referenced and how it was referenced.

As well as seeing if the old code referenced what was a local array SIGR and how it was referenced.

See if these variables were required to be separate.

And, did this naming error get introduced by some change you made to the original code.

Jim Dempsey

[Qaiser_Bozdar]

@jimdempseyatthecove 

>> a) The old code was in error

I have windows XP running in a virtual machine.  I have both Digital visual FORTRAN Professional Edition 5.0A compiler and MS Visual Developer (1994-97) in it. The older code is executed without any trouble and performing its work as it is programmed in that version. Even SIGE is declared in the whole code, one time only. Its syntax matches with FORTRAN 90 or FORTRAN 77. 

At this time, I need a compiler which can execute the older code without the need of any kind of modification in a latest environment (Windows-10/11 in Core I5/I7 computers). But I have not found any compiler yet. Hence, I am using Intel FORTRAN Compiler which might execute the code after some modifications. 

When I first compiled the older code in Intel FORTRAN compiler, it gave me errors related to (1) the comments (such as * and c were used in older code as a comment). I removed replace those (* and c ) with ! (mark). Line by line. Errors related to (2) the array bound limit (such as there was an array declared X(0)=0.0) I changed that to (X(1)=0.0). Errors were removed. 

(3) third error was this SIGE and SIGR. 

Now, I am facing a debug error. I am still looking into it. Even my office is off on Saturday and Sunday. 

The older code even don`t have any main function that is (program and end program). The older code is working well in windows XP in virtual machine, in which I have Digital visual FORTRAN Professional Edition 5.0A compiler, and MS Visual Developer (1994-97). 

[andrew_4619]

You are missing the point I think. The  SIGE/SIGR thing is a error in the code. The code may run OK in the old compiler for a number of reasons for example SIGE/SIGR might not be used or modified in the subprogram. If they are used  because you have  non conforming Fortran code then what the older compiler does to make "working code " is either by some intent or just luck based on the compiler design choices. To expect a more modern compiler to do the same things with non conforming Fortran is not realistic, non-conforming code does not have a designed intent as far as a compiler writer is concerned. You need to understand what the code does and fix it. Getting it to compile without error is not fixing it.

[Qaiser_Bozdar]

@andrew_4619  

Thank You, I got the point. I am looking into all the possible solutions I have, to modify and run that code. If failed to do that:

My next goal: I will re-write all the code again with new format of FORTRAN 90, and make it to compile in Intel FORTRAN Compiler. I mean, I will again perform the work of formula translation using new standards of FORTRAN. I will develop a new modern code for that old program. No need to modify that old code.