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

Tue Sep 27 22:37:21 CDT 2011

PS. Please redistribute the test program that was contained in Rolf's original email.

-----Original Message-----
From: Supalov, Alexander 
Sent: Wednesday, September 28, 2011 12:21 AM
To: MPI-3 Fortran working group
Subject: RE: [MPI3 Fortran] Fwd: Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION
Importance: High

Hi,

I'm surprised to see no Intel MPI on the list below. Both Intel MPI and MS MPI are based on MPICH2. Please add me (for Intel MPI) to this kind of announcement from now on. We also make Intel compiler, so it makes a lot of sense to ask at the source rather than elsewhere.

Best regards.

Alexander

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Rolf Rabenseifner
Sent: Tuesday, September 27, 2011 5:22 PM
To: MPI-3 Fortran working group
Subject: [MPI3 Fortran] Fwd: Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION

For your info:
I informed the providers of independent MPI libraries with Fortran bindings about a serious problem with the definition of Fortran datatypes.

My apologies if I missed some of the independent MPI libraries.

In this case, please also run the program and please send the result to me.

Best regards
Rolf

----- Forwarded Message -----
From: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
To: "Richard Treumann" <treumann at us.ibm.com>, "Rajeev Thakur" <thakur at mcs.anl.gov>, "Jeff Squyres" <jsquyres at cisco.com>, "Shinji Sumimoto" <s-sumi at labs.fujitsu.com>, "Hubert Ritzdorf" <hubert.ritzdorf at emea.nec.com>, "Fab Tillier" <ftillier at microsoft.com>
Sent: Tuesday, September 27, 2011 5:15:15 PM
Subject: Serious problem/bug in MPI libraries with the alignment of MPI_DOUBLE_PRECISION

Dear all,

as far as I know, you represent some MPI libraries that are not directly based on another one in the list:
 - mpich2: Rajeev
 - OpenMPI: Jeff
 - IBM: Rich Treumann
 - NEC: Hubert
 - Fujitsu: Shinji Sumimoto
 - Microsoft: Fab
(Which independent library is missing on this list?) (Who of the list uses already mich2 or OpenMPI as bases  or does not provide a Fortran binding,  and can be therefore removed from this list?)

The problem is simple and has at the end only three numbers:

  Aligments of:
   - DOUBLE PRECISION within a SEQUENCE derived type = 4 (e.g. with Intel)
   - DOUBLE PRECISION within a BIND(C)  derived type = 8
   - MPI_DOUBLE_PRECISION (= k_i in MPI-2.2 p.78:45) = 4 or 8

The details: 
Which is the alignment of Fortran DOUBLE PRECISION according to k_i on MPI-2.2, page 78 line 45 and page 96 line 42.

Since 1977 (Fortran 77) in Fortran COMMON blocks and 1990 (Fortran 90) in Fortran SEQUENCE derived types (which have the same memory layout according to the SEQUENCE-rules), the MPI alignment and the Fortran alignment in such constructs should be the same, e.g., the Intel compiler has alignment 4 !!!

This may be significantly different to C, where Intel uses alignment 8!

With Fortran 2003, we got the Fortran BIND(C) derived types.
Here, a Fortran DOUBLE PRECISION has with Intel's compiler the aligment 8.

As far as I understand, mpich2 and Cray produce following results with an Intel compiler:

Aligments of:
 - DOUBLE PRECISION within a SEQUENCE derived type = 4
 - DOUBLE PRECISION within a BIND(C)  derived type = 8
 - MPI_DOUBLE_PRECISION (= k_i in MPI-2.2 p.78:45) = 8

This is definitely wrong compared to MPI-1.1 and MPI-2.0 but may be helpful for MPI-3.0 when we like to switch to a definition that is based on BIND(C).

Question:
What is the output of the attached test program when running with
 - your MPI library
 - and your compiler
 - and with Intel's compiler

Please can you send me the output of such mpiruns?

Thanks in advance and best regards
Rolf

PS: We need not to care about 8/8/8.
    Only 4/8/x causes problems:
    If all those have x=8 then I'll propose to 
    adopt the MPI-3.0 to the reality.
    If we have some implementations with 4/8/8 and
    others with 4/8/4 then we have a serious problem
    because only one answer can be correct,
    and the question would be whether the historical
    answer (x=4) or the modern answer (x=8)
    should be chosen.

--
Dr. Rolf Rabenseifner . . . . . . . . . .. email 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 Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

--
Dr. Rolf Rabenseifner . . . . . . . . . .. email 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 Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland 
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052