[MPI3 Fortran] Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION

[Rasmussen, Craig E]

Rolf,

I don't know where you get the idea that a DOUBLE PRECISION variable should occupy 4 bytes.  The standard says:

A nonpointer scalar object of type double precision real or default complex occupies two contiguous numeric storage units;

The derived types we worked out in Santorini were especially constructed so that double precisions numbers would be misaligned if the compiler was forced to do bad things via the SEQUENCE statement.  Can you give me an idea which part of the tests we wrote indicate a double precision number is 4 bytes?

Also, I checked the F2003 and F2008 standards and this wording (see above) has not been changed.

-craig


On Sep 28, 2011, at 11:00 AM, Rolf Rabenseifner wrote:

A very good question. Instead of referring to SEQUENCE, it should say
that MPI_DOUBLE_PRECISION would use the numeric storage sequence rules
(16.4.3.1 in Fortran 2003) for alignment.

Nick,
please can you explain, what "16.4.3.1 in Fortran 2003" tells
about alignments.
In SEQUENCE derived types and COMMON blocks,
when I understand this correctly, then DOUBLE PRECISION
must have also one numerical storage unit as alignment,
i.e., with REAL=4 bytes, DOUBLE PRECISION alignment must be
also 4 byte, i.e., exactly what the Intel compiler is doing
in a SEQUENCE derived type or COMMON block.

The implication is that the compiler issues nice "warnings" about
misaligned data.

Do I understand correctly, that the other compilers with
REAL-size=4 byte and DOUBLE PRECISION size and alignment = 8 byte,
do it wrong, i.e.not according to Fortran 2003 or 2008?

Best regards
Rolf

----- Original Message -----
From: "N.M. Maclaren" <nmm1 at cam.ac.uk<mailto:nmm1 at cam.ac.uk>>
To: "Fab Tillier" <ftillier at microsoft.com<mailto:ftillier at microsoft.com>>
Cc: "Rolf Rabenseifner" <rabenseifner at hlrs.de<mailto:rabenseifner at hlrs.de>>, "Jeff Squyres" <jsquyres at cisco.com<mailto:jsquyres at cisco.com>>, "Shinji Sumimoto"
<s-sumi at labs.fujitsu.com<mailto:s-sumi at labs.fujitsu.com>>, "Hubert Ritzdorf" <hubert.ritzdorf at emea.nec.com<mailto:hubert.ritzdorf at emea.nec.com>>, "Howard Pritchard" <howardp at cray.com<mailto:howardp at cray.com>>,
"Brian Smith" <smithbr at us.ibm.com<mailto:smithbr at us.ibm.com>>, "Charles J Archer" <archerc at us.ibm.com<mailto:archerc at us.ibm.com>>, "Rajeev Thakur" <thakur at mcs.anl.gov<mailto:thakur at mcs.anl.gov>>,
"Bill Long" <longb at cray.com<mailto:longb at cray.com>>, "Bill Gropp" <wgropp at uiuc.edu<mailto:wgropp at uiuc.edu>>, "Richard Graham" <rlgraham at ornl.gov<mailto:rlgraham at ornl.gov>>, "Iain Bason"
<iain.bason at oracle.com<mailto:iain.bason at oracle.com>>
Sent: Wednesday, September 28, 2011 10:26:37 AM
Subject: RE: Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION
On Sep 27 2011, Fab Tillier wrote:

It seems that all the a == 4 results come from using the Intel
Fortran
compiler suite. Given that Microsoft doesn't ship a Fortran
compiler,
mandating a == 8 doesn't put us in a position to succeed. Therefore,
I
cannot support such a proposal.

I agree that Microsoft should not be forgotten, but it is not a major
platform for MPI use, and the tail should not wag the dog. We have the
ghastly example of C99 long long where some people claimed Microsoft
compatibility required an incompatible change to the standard; largely
as a result, the official C standard is no longer used as a portable
programming base by a good half of the C-using community.

however, shouldn't a DOUBLE PRECISION BIND(C) derived type map to
MPI_DOUBLE, not MPI_DOUBLE_PRECISION?

Can't we simply document that MPI_DOUBLE_PRECISION (and any Fortran
types
that need similar treatment) apply only to SEQUENCE derived types,
while
BIND(C) derived types should use the C types?

A very good question. Instead of referring to SEQUENCE, it should say
that MPI_DOUBLE_PRECISION would use the numeric storage sequence rules
(16.4.3.1 in Fortran 2003) for alignment.


Slightly related to this, can't we PLEASE deprecate those horrible
MPI_INTEGER8 etc. types? They have been a portability disaster for
half a century, even among Fortran IV compilers (where they started)!
MPI has provided some perfectly good mechanisms to use Fortran's
selectable KINDs. The reason that it is related is that there is no
guarantee that a compiler will give them the same alignment as another
type even if they use the same storage, because they are non-standard
and therefore any specification is the compiler's choice.


Regards,
Nick Maclaren.

--
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de<mailto:rabenseifner at hlrs.de>
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<http://www.hlrs.de/people/rabenseifner>
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org<mailto:mpi3-fortran at lists.mpi-forum.org>
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20110928/91d09d7a/attachment-0001.html>