I know of no plans to fix the underlying problems. buildiface can be told to generate code for the case where MPI_Fint is different from int, but this doesn’t address the use of the C interface from within the Fortran wrappers. Bill On May 20, 2015, at 3:43 AM, Jeff Hammond <[email protected]> wrote:

I'm not aware of any place in the standard where it says that implementations do not have to support the full 64b range of a Fortran INTEGER when the compiler ordains that INTEGER is that size. MPICH is at best dangerous when a Fortran INTEGER is larger than a C int.

The tail of mpif_h/sendf.c shows this problem:

/* Prototypes for the Fortran interfaces */ #include "fproto.h" FORT_DLL_SPEC void FORT_CALL mpi_send_ ( void*v1, MPI_Fint *v2, MPI_Fint *v3, MPI_Fint *v4, MPI_Fint *v5, MPI_Fint *v6, MPI_Fint *ierr ){ *ierr = MPI_Send( v1, (int)*v2, (MPI_Datatype)(*v3), (int)*v4, (int)*v5, (MPI_Comm)(*v6) ); }

The origin of the issue appears to be the unsafe cast generated by mpif_h/buildiface:

sub fint2int_inout_decl { my $count = $_[0]; if ($within_fint) { print $OUTFD " int l$count = (int)*v$count;\n"; }

This is not just academic for me. I know that unsafe down-casting inside of MPI breaks multiple quantum chemistry applications. And while I wrote BigMPI in part to address this issue, users would be much happier if MPICH and its derivatives were sufficient.

Is there any plan to address this? It appears to require lots of code changes. For example, one could add e.g. MPIR_Send that takes mpid_size_t (or similar) counts and call that (instead of MPI_Send) from Fortran, as well as map C MPI_Send to it. Of course MPID_Send would also have to convert to mpid_size_t and so forth across all the routines and down the stack.

Comments?

Thanks,

Jeff

-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel