I think I like d the most but it is not a perfect solution. With d all
real8 types in a common will be badly aligned and the Open MPI
internal datatype will be incorrect. So I will vote for a combo: b +
On Fri, May 30, 2014 at 4:57 AM, Gilles Gouaillardet
> 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
> the issue.
> 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 ?
> devel mailing list
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: