[MPIWG Fortran] Type of MPI_Status

Bill Long longb at cray.com
Mon Mar 17 14:21:08 CDT 2014

On Mar 17, 2014, at 2:10 PM, Junchao Zhang <jczhang at mcs.anl.gov> wrote:

> There is a problem with this approach.  If the normal INTEGER and c_int are the same, then INTEGER compiled with a switch like -i8 is almost assured to be different from c_int.   It is not that hard to write the module such that a single source can be used to compile both -i4 and -i8 versions.  There should not be measurable overhead with this, since the checks are all on compile-time constants, so the checks and the “unused” branch of the test will be eliminated by the compiler.
> The compiler eliminates the unused branch in an MPI implementation at the library build time. But later, you use a different sized INTEGER at user code compilation time (through mpif90 options?). That is erroneous. 

No. You have to build two versions of the module .mod and .o files.  One without -i8 and one with -i8 (usually actually something like default 4 and 8, to cover REAL as well, but taking care of the cases of REAL in the MPI module is trivial).  When you compile the user code, the compile script detects the -i8 option and references the correct .mod file. The link step gets the right .o files.   This has been happening for years.   The point of the module design is to have only one copy of the module source that will generate the correct code based on how it is compiled, and also to insulate the C part of the library from this issue, so that only one copy of that is needed. 


> Why there is runtime overhead when INTEGER = c_int, see my previous reply to Rolf on comparison of designs with INTEGER MPI_Status or with INTEGER(c_int) MPI_Status. 

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

More information about the mpiwg-fortran mailing list