Thanks for reply. Yes, unfortunately we need fortran interfaces because most of the applications that we use for testing are written in fortran. Will it be enough if I just add a conversion rule to %parmc2f in ./src/binding/f90/buildface? Something like: 'MPI_Pattern' => 'INTEGER(KIND=MPI_ADDRESS_KIND)', 'MPI_Pattern*' => 'INTEGER(KIND=MPI_ADDRESS_KIND)', And for f77 it will be: 'MPI_Pattern' => 'MPI_Fint *' 'MPI_Pattern*' => 'MPI_Fint *'

Also, as a side note, please use "MPIX_" for nonstandard MPI extensions. It makes nonstandard interfaces very obvious to users and will help prevent potential issues with standardization in the future.

Duly noted. Tatiana 2013/3/28 Dave Goodell <[email protected]>:

On Mar 28, 2013, at 2:16 PM CDT, Tatiana V. Martsinkevich <[email protected]> wrote:

...

We are implementing some fault tolerance related functionality in MPICH-3.0.2. We define a new MPI type in ~/mpich-3.0.2/src/include/mpi.h.in as:

typedef void* MPI_Pattern;

then in the same file we define:

int MPI_Pattern_declare(char* name, MPI_Pattern* handler);

However, when I run autogen.sh and fortran binding script executes it gives out:

Pattern_declare: No parm type for MPI_Pattern* (MPI_Pattern*) Use of uninitialized value $fparm in pattern match (m//) at ./buildiface line 1289, <FD> line 1710.

Do you want Fortran interfaces at this time or would you be just as happy to have C-only bindings right now? The former will require hacking on one or more of the "buildiface" scripts in the "src/binding/LANGUAGE" directories. The latter can be accomplished by moving your prototypes and types near the end of mpi.h.in, near the prototypes for "MPIX_Mutex_unlock" and "PMPIX_Mutex_unlock".

Also, as a side note, please use "MPIX_" for nonstandard MPI extensions. It makes nonstandard interfaces very obvious to users and will help prevent potential issues with standardization in the future.

-Dave