Warning - routine called with different number and/or type of actual arguments

[frank_peacock]

Hello

I received this error message with a lot of MPI subroutine calls:

Warning: Routine MPI_BCAST called with different number and/or type of actual arguments in earlier call - C attribute required if intended.

A typical call was the following where caseid is an 8-character variable:

call MPI_BCAST(caseid ,8 ,MPI_CHARACTER ,0,MPI_COMM_WORLD,ier)

What I don't understand is that there was no previous call made regarding that variable. The calls were mainly mpi_bcast calls, although there were also a single mpi_unpack and mpi_recv call too. Most of the warnings which result in access violations in run-time are ones which have a MPI_CHARACTER variable type.

Can anyone suggest a way to resolve the problem?

Thank you

Frank Peacock

[TimP]

The error message is simply telling you that you called MPI_BCAST with differing numbers or type declarations of arguments from the same compilation unit. It doesn't check variable names. In fact, one of them may have been misspelled, or a declaration missing, or, in fixed form input, you may have something out of column fields.

[frank_peacock]

Hello again

I have checked the code and it appears that the warnings are correctly identifying that the subroutine callshave different argument types in different calls. I am sure the code is correct as it is public domain and has been compiled on other computers. What Idon't understand is the run-time errors I am getting of type "access violation". Is it necessary to specify that the calls are correct, that is, to do something in regard to the warning's "C attribute required if intended"?

Thank you

[TimP]

Maybe someone got away with this on some system, but Windows is not the only system which requires consistent handling of stack by caller and callee. Your run time errors make it look as if this is indeed a problem. You might want to consult the documentation of the version of MPI for which this was originally written, to see if a varying number of arguments was supported, and if there is a clue as to how to make it portable. Otherwise, I would guess that a missing trailing argument might be copied from a previous call. As MPI_BCAST is specified in MPI standards, and I've never seen this problem, I'm skeptical that the varying number of arguments could be considered "correct." The oldest MPI standard I can find easily by Googling is specific about the calling sequence, although it documents only the C view of it:
http://www.mpi-forum.org/docs/mpi-11-html/node67.html#Node67

[Steven_L_Intel1]

You are calling the routine with the STDCALL calling mechanism, the default in CVF. This requires that the number of arguments match, or else you will get stack corruption. If you used the ALIAS attribute to "correct" the name of the routine, you also need to add the C attribute to fix the calling mechanism. See the Programmer's Guide chapter on mixed-language programming for more information.

[frank_peacock]

Hello Tim18 and Sblionel

It seems you have both understood the problem to be in regard to the number of arguments. It is not. It is varying argument types, the firstargument in particular, which can be integer or character. I presume that the default is passing by value and that the C attribute is needed for ensuring that it is passed by reference. What do I need to do for each offending statement in order to intend using the calls as they are written now.

Thanks

[greldak]

Are you saying at you are trying to call different versions of an overloaded routine in the library?

[Steven_L_Intel1]

There is nothing to be done at the call statement. You have to add a

!DEC$ ATTRIBUTES C,REFERENCE :: routinename

directive for each routine you are calling, so that it is visible to the routine doing the call. You could put these in an INCLUDE file, for instance. An alternative is to simply build your application with /iface:cref (Project..Options..Fortran..External Procedures..Calling Mechanism..C, By Reference

[TimP]

Better check that the Windows MPI you are targeting is consistent with your assertion about the possibility of varying types of the first argument to BCAST. All of the examples I have in front of me use the first argument consistently as integer, by reference, and no warnings about inconsistent types from any Fortran compiler. Most, but not all, Fortran compilers will add an additional hidden character length argument to the argument list, either right after the CHARACTER argument, or at the end. Either way, you have both argument type and number mismatch between calls with INTEGER and CHARACTER. It seems a little far fetched that the callee would be written in C in such a way as to detect the extra argument, figure out which one is a character length argument, and do the right thing for the different cases you have set up.

[frank_peacock]

Hello Steve

I have tried your suggestion of putting in a single !DEC ATTRIBUTES statemenent for the subrouting MPI_BCAST. It results in no warnings during compilation but during linking the following error occurs:

"distnl.obj : error LNK2001: unresolved external symbol _mpi_bcast".

What appears perplexing is that this subroutine can be called without run-time errors with standard calling protocol until the change of argument type when the "access violation" occurs at the warned statement.

I cannot put a compiler switch in because there is another library which works with standard calls (not to mention the fact that other calls to the MPI library cause linker errors).

What do you think?

Frank

[frank_peacock]

Hello Tim

I have checked the MPI manual for the library I am using and its first argument is a pointer of type void.

Frank

[Steven_L_Intel1]

You need to determine what calling conventions your MPI library needs. If it is built for STDCALL, with the @n suffix on the global names, you must always call the routines with the same number of arguments - no exceptions. It may be that you have to pass unusued arguments for consistency.

If the library is built for C calling conventions, then you can change the number of arguments. In either case, you have to study the documentation for the library to see what it is expecting.

[frank_peacock]

Hello Steve and Tim

I have checked the manual and the number of arguments is constant for different types of calls and I think it adheres toSTDCALL since all of the calls prior to the change in argument type are processed correctly. The first argument in the MPI_BCAST call according to the manual is a buffer variable, a pointer of type void. Given these, can you suggest a solution?

Frank

[Jugoslav_Dujic]

Frank, I didn't follow the thread too closely, but it appears that, in order to match (void*), you need to pass the actual argument like:

call mpi_bcast(%VAL(LOC(arg)), ...

This effectively passes the first argument (whatever its type is) only by reference (no additional length for strings).

Jugoslav

[frank_peacock]

Hello Jugoslav

Thank you foryour help. Your trick did the job.

Thanks a million.

Frank