On Aug 15, 2005, at 5:55 PM, Ben Allan wrote:
I deal with mixed-language c/c++/fortran codes and it appears I might
be able to define an inter-language opaque reference (e.g. a Comm) as
C int64t for passing to fortran and using the MPI_Comm_c2f/f2c macros
to encode/decode it on the C side.
Based on reading your entire post, it sounds like you are trying to
have a Fortran-compiler-independent application/library (i.e., have
software that works regardless of what size the Fortran compiler uses
for INTEGER). Is that right?
The MPI standard says that on the FORTRAN side the object handles are
of type INTEGER. Presumably, then to make sure things are not done
accidently, the FORTRAN interface receiving such an integer from C
would declare it INTEGER*8, not default the integer size at the whim
of the FORTRAN compiler. On the fortran side, one might need to step
the int64t down to an int32t (INTEGER*4) before calling to MPI on some
of the compilers I know of today.
(I assume you're talking about your application here, not the MPI
implementation, right?)
Yes, I don't see any reason this won't work, but be sure you don't pass
INTEGER*8's into MPI Fortran calls directly. A trivial example
example:
call MPI_COMM_SIZE(comm, size, ierr)
comm, size, and ierr should still be INTEGERs, or the MPI
implementation's C code is going to run into problems (i.e., it's going
to assume that it receives pointers to items that are of the same
length as sizeof(INTEGER)).
My question for the MPI implementation wizards is:
Does anyone know of a current platform where f90 INTEGER is *bigger*
than C int64t/INTEGER*8 (e.g. default is INTEGER*16, yikes!) or a
where misplaced fortran compiler option might make that true?
I'm not enough of a Fortran wizard to know, but I will say that in
LAM's and Open MPI's configure scripts, we dynamically figure out the
size of a Fortran INTEGER and find a corresponding C integer type for
it. I have not personally see a case where we couldn't find a matching
C integer type (and we certainly don't assume that int128_t exists! :-)
), but you shouldn't take that as an iron-clad guarantee...
Due to an automated code generator in the processing (babel) I have to
pick one of INTEGER*4 or INTEGER*8 and stick to it. I'm guessing
INTEGER*4 would be a poor choice for MPI opaque objects in calling on
some MPI implementations.
As long as your code can handle the transfer from your type back and
forth to an INTEGER, you should be ok.
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
