[mpich-devel] binding a new MPI type with fortran

Tatiana V. Martsinkevich tanya.manekineko at gmail.com
Thu Mar 28 15:04:44 CDT 2013


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 <goodell at mcs.anl.gov>:
> On Mar 28, 2013, at 2:16 PM CDT, Tatiana V. Martsinkevich <tanya.manekineko at gmail.com> 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
>


More information about the devel mailing list