The number of actual arguments cannot be greater than the number of dummy arguments

[Gary_E_]

The following code is giving the compile-time error #6784: The number of actual arguments cannot be greater than the number of dummy arguments.

SOURCE1.f

CHARACTER*4 Mode

INTEGER Iflag

REAL(1000) a

INTEGER b

REAL*8, DIMENSION(1:302) :: c

REAL*8, DIMENSION(1:300) :: d

...

call prog_in(Mode,Iflag,a,b,c,d)

SOURCE2.f

subroutine prog_in(mode,iflag,a,b,c,d)

CHARACTER*4 Mode

INTEGER Iflag

REAL(1000) a

INTEGER b

REAL*8, DIMENSION(1:302) :: c

REAL*8, DIMENSION(1:300) :: d

I know that Fortran by default passes the length of character arguments at the end of the argument list. For this project however, this is changed such that Fortran passes the length of character arguments immediately after the individual string arguments.

I tried to insert an additional argument in the SOURCE2 definition:

subroutine prog_in(mode,modelen,iflag,a,b,c,d)

INTEGER modelen

But I still get the same compile-time error.

Any thoughts?

[Gary_E_]

When I removed the CHARACTER argument 'Mode' from both the CALL prog_in(...)and the SUBROUTINE prog_in(...) I am still getting error #6784 on the CALL line.

Additionally, now I am getting multiple error #6633 instances (The type of the actual argument differs from the type of the dummy argument) on the arguments Iflag, a, b, and c.

I also get error #6634 instances (The shape matching rules of actual arguments and dummy arguments have been violated) on the arguments a and c.

I'm not using any MODULE statements in the code. It's a simple CALL and pass of the arguments between a couple of subroutines.

[mecej4]

You can have REAL(4) and REAL(8), but

REAL(1000) a

is not a KIND of REAL that is supported. Perhaps you want

REAL a(1000)

[Gary_E_]

Whoops... I mistyped the declaration...

In all cases it's:

REAL a(1000)

Sorry for that.

[Gary_E_]

I wouldn't even want to know how big of an integer a REAL(1000) could theoretically hold...

[andrew_4619]

I would have thought there should be an error for invalid kind as that is the code error. I think I would consider that a compiler bug

[Steven_L_Intel1]

How about attaching a complete, real source file that demonstrates the problem? You should not try to reflect the hidden length in the argument list (unless you're calling a non-Fortran language). Your paraphrase doesn't reflect your actual code.

[Gary_E_]

Unfortunately I can't attach a complete, real source file. That's exactly what I thought regarding the hidden length of character arguments in the argument list. I was trying to isolate if it was the CHARACTER argument that was causing the issue.

Today when I opened up the same project containing the two source files in question, I received the message: "The line endings in the following files are not consistent. Do you want to normalize the line endings?" I'm working on a Windows OS and the end program is for Windows so I chose WINDOWS CR LF. Somehow this got me past error #6784 on that particular call combination. Now I'm getting another error #6784 for a similar call combination but with two other files. I closed out the solution and re-opened it again but no line endings message.

Is there any way to force consistency of the line endings within the IDE?

[Gary_E_]

Is there any way to get the IDE to show in more detail why the number of actual arguments is not greater than the number of dummy arguments for a particular call? In other words, can it show me specifically that the CALL subroutine argument list is X, Y and Z and the called SUBROUTINE argument is X, Y, Z, and A??

[Gary_E_]

Something must be wacky with the Debug environment... leftover muda lingering around. I'll puzzle this out.

[Steven_L_Intel1]

It tells you the routine you're calling - you can use Go To Definition to go to it. You might have "stale" generated interface modules, in which case a Rebuild should take care of it.

The line ending message has no correlation whatsoever with the compiler diagnostics.

[Gary_E_]

That's exactly it. I did some research online and found that a rebuild was likely the solution - so now life is OK again. At least next time I'll think to "reboot" the solution before trying to chase down ghosts. Thanks all.