i recently had to solve a tricky issue that involves alignment of fortran
the attached program can be used and ran on two tasks in order to evidence
if gfortran is used (to build both openmpi and the test case), then the
test is successful
if ifort (Intel compiler) is used (to build both openmpi and the test
case), then the test fails.
this was mentionned in the openmpi users list quite a while ago at
the root cause is gfortran considers mpi_real8 must be aligned on 8 bytes
whereas ifort considers mpi_real8 does not need to be aligned.
consequently, the derived data type ddt is built with an extent of 16
(gfortran) or 12 (ifort)
in order to determine the type aligment, configure builds a simple program
with c and fortran that involves common.
the default behaviour of ifort is to :
- *not* align common
- align records (aka the real8_int fortran type)
hence the mismatch and the failure.
the default behaviour of gfortran is to align both common and records,
hence the success.
/* i "extracted" from configure conftest.c and conftestf.f that can be used
to build the conftest binary. conftest will store the alignment in the
conftestval file */
i am wondering how this should be dealt by OpenMPI.
here is a non exhaustive list of option :
a) do nothing, this is not related to openmpi, and even if we do something,
application built with -noalign will break.
b) advise ifort users to configure with FCFLAGS="-align zcommons" since it
is likely this is what they want
c) advise ifort users to build their application with "-noalign" to be on
the safe side (modulo a performance penalty)
d) update OpenMPI so fortran type alignment is determined via a record
instead of a common if fortran >= 90 is used
(so far, i could not find any drawback in doing that)
e) advise ifort users to create ddt with MPI_DOUBLE instead of mpi_real8
(because this works (!), i did not dig to find out why)
f) other ...
any thoughts ?