[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