MSMPI's mpif.h uses:
INTEGER MPI_ADDRESS_KIND
PARAMETER (MPI_ADDRESS_KIND=INT_PTR_KIND())
This intrinsic is available in Intel Fortran and PGI Fortran, but not in gfortran. The modern Fortran 2003 way to solve this would be:
use, intrinsic :: iso_c_binding
INTEGER MPI_ADDRESS_KIND
PARAMETER (MPI_ADDRESS_KIND=c_intptr_t)
But since the mpif.h header is meant to be used for legacy code (and maybe legacy compilers) it is probably better not to rely on such a relatively new feature.
I noticed that a MSMPI-specific workaround for such issues is already in place by separating out architecture-specific bits into the {x64,x86}/mpifptr.h file which is included from mpif.h and currently only contains (x64 variant):
INTEGER MPI_AINT
PARAMETER (MPI_AINT=z'4c00083b')
This could be extended to include the MPI_ADDRESS_KIND parameter. For x64:
INTEGER MPI_ADDRESS_KIND
PARAMETER (MPI_ADDRESS_KIND=8)
For x86:
INTEGER MPI_ADDRESS_KIND
PARAMETER (MPI_ADDRESS_KIND=4)
And removing the parameter from mpif.h itself.
The current nasty work-around for this is to add the following preprocessor definition to all files including the mpif.h header:
gfortran -DINT_PTR_KIND\(\)=8 "-I$MSMPI_INC" "-I$MSMPI_INC/x64" "-L$MSMPI_LIB64" ...
Adapting MS MPI seems like an easy fix, would make the life of gfortran users easier and be in general standards conformant. Together with my other two reported issues this would make gfortran work out of the box with MS MPI and avoids devs wasting hours digging
through the web trying to make things compile. Most solutions are just half-correct, so it would be better to solve this at the core.
Does this make sense? Did I forget to consider something?
