Done. Tatiana 2013/3/29 Rajeev Thakur <[email protected]>

Another reminder that you should call it MPIX_Pattern instead of MPI_Pattern.

Rajeev

On Mar 29, 2013, at 3:11 PM, Tatiana V. Martsinkevich wrote:

...

Hello,

Thanks again for your help Dave.

So we went the other way around and changed the type of MPI_Pattern from void* to integer and now fortran interfaces are being generated correctly. However, now the question is how to register the new type MPI_Pattern so that we could use it in fortran programs. This also doesn't seem to be trivial...

In buildface there are this kind of code sections:

# Datatypes # These are determined and set at configure time foreach $key (COMPLEX, DOUBLE_COMPLEX, LOGICAL, REAL, DOUBLE_PRECISION, INTEGER, '2INTEGER', '2DOUBLE_PRECISION', '2REAL', CHARACTER) { print MPIFFD " INTEGER MPI_$key\n"; print MPIFFD " PARAMETER (MPI_$key=\@MPI_$key\@)\n"; }

this looks like where I should start digging but apparently, simply adding PATTERN to the key set doesn't work:

Included at src/binding/f90/mpi_constants.f90:6:

PARAMETER (MPI_PATTERN=@MPI_PATTERN@) 1 Error: Expected expression at (1) in PARAMETER statement

Also, could someone please explain what does this notion - @MPI_COMPLEX@- in mpi.h.in mean

/* Fortran types */ #define MPI_COMPLEX ((MPI_Datatype)@MPI_COMPLEX@)

regards, Tatiana

2013/3/28 Dave Goodell <[email protected]> You almost certainly will also need some modifications in "src/binding/f77/buildiface". Whenever I need to modify this script I have to stare at it for a while before I'm sure where the modifications need to go.

I don't think we have any existing types which map to pointers under the hood. So there isn't a good example for you to use here. The "MPI_Fint *" changes in particular do not seem correct to me in general. They *might* work in a pinch on a platform with where INTEGER and (void*) are the same size. They might also work on little endian platforms like x86/x86_64, but it will be purely by luck if they do.

You may be better writing your own Fortran bindings by hand in the short term.

Bill may have something to add on this subject, since he's the primary maintainer for these scripts.

-Dave

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

...

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