Introduction

This page contains information and discussion about errors, ambiguities, and clarifications in the MPI standard. No part of this document is official. See the MPI Forum web site for official errata. The MPI Forum's MPI 2.1 web site has additional information on the evolution of MPI, including the official status of errata items.

Comments on the MPI standard should be mailed to mpi-core@mpi-forum.org. Page and line numbers refer to the official MPI-2 document, not the HPCA issue or the 2nd edition of the Complete Reference.

Useful links:

Current Open Topics

Obvious Errors and Inconsistencies

These items are errors and inconsistencies in the standard, such as misspellings, and omissions. These are suitable for inclusion in the MPI-2 errata.
C++ and Fortran Complex
Mail discussing See also Mail discussing complex and bool

This needs more discussion. The problem is that some of the C++ datatypes have no easily defined counterparts in C or Fortran. The minimum fix is really a clarification that says that there is no interlanguage support for the C++ complex types.
Proposed text

Page 276, after line 4, add

Advice to users.
Most but not all datatypes in each language have corresponding datatypes in other languages. For example, there is no C or Fortran counterpart to the MPI::BOOL or the the MPI::COMPLEX, MPI::DOUBLE_COMPLEX, or MPI:LONG_DOUBLE_COMPLEX. End of advice to users.

Extending the C++ datatypes to C and Fortran needs to include MPI::BOOL as well as the complex types, and should define what the equivalent types are in C and Fortran. The real issue here is the MPI:F_COMPLEX and completing the list of such routines.
MPI_ALLTOALLW
Mail discussing
The displacements in MPI_ALLTOALLW are in bytes but the language binding uses int and INTEGER instead of MPI_Aint and INTEGER (KIND=MPI_ADDRESS_KIND).
Proposed text
Page 165, lines 25-38 read
int MPI_Alltoallw(void *sendbuf, int sendcounts[], int sdispls[], 
              MPI_Datatype sendtypes[], void *recvbuf, int recvcounts[], 
              int rdispls[], MPI_Datatype recvtypes[], MPI_Comm comm) 

MPI_ALLTOALLW(SENDBUF, SENDCOUNTS, SDISPLS, SENDTYPES, RECVBUF, RECVCOUNTS, 
              RDISPLS, RECVTYPES, COMM, IERROR) 
<type> SENDBUF(*), RECVBUF(*)
INTEGER SENDCOUNTS(*), SDISPLS(*), SENDTYPES(*), RECVCOUNTS(*), 
RDISPLS(*), RECVTYPES(*), COMM, IERROR 

void MPI::Comm::Alltoallw(const void* sendbuf, const int sendcounts[], 
             const int sdispls[], const MPI::Datatype sendtypes[], void* 
             recvbuf, const int recvcounts[], const int rdispls[], const 
             MPI::Datatype recvtypes[]) const = 0

but should read 

int MPI_Alltoallw(void *sendbuf, int sendcounts[], MPI_Aint sdispls[], 
              MPI_Datatype sendtypes[], void *recvbuf, int recvcounts[], 
              MPI_Aint rdispls[], MPI_Datatype recvtypes[], MPI_Comm comm) 

MPI_ALLTOALLW(SENDBUF, SENDCOUNTS, SDISPLS, SENDTYPES, RECVBUF, RECVCOUNTS, 
              RDISPLS, RECVTYPES, COMM, IERROR) 
<type> SENDBUF(*), RECVBUF(*)
INTEGER SENDCOUNTS(*), SENDTYPES(*), RECVCOUNTS(*), RECVTYPES(*), COMM, IERROR 
INTEGER (KIND=MPI_ADDRESS_KIND) SDISPLS(*), RDISPLS(*)

void MPI::Comm::Alltoallw(const void* sendbuf, const int sendcounts[], 
             const MPI::Aint sdispls[], const MPI::Datatype sendtypes[], 
             void* recvbuf, const int recvcounts[], const MPI::Aint rdispls[],
             const MPI::Datatype recvtypes[]) const = 0
These modifications also need to be made in Appendix A.6.4, A.7.4, A.8.4:
  • page 312, line 34 (C)
  • page 322, line 41 (Fortran)
  • page 335, line 16 (C++)
MPI_ALLTOALLX
This is an alternative to the MPI_ALLTOALLW proposal above. Mail discussing
Page 164, line 16-30 should read:

7.3.5. Generalized All-to-all Functions
One of the basic data movement operations needed in parallel signal processing is the 2-D matrix transpose. This operation has motivated two generalizations of the MPI_ALLTOALLV function. These new collective operations are MPI_ALLTOALLW and MPI_ALLTOALLX; the ``W'' indicates that it is an extension to MPI_ALLTOALLV, and ``X'' indicates that it is an extension to MPI_ALLTOALLW. MPI_ALLTOALLX is the most general form of All-to-all. Like MPI_TYPE_CREATE_STRUCT, the most general type constructor, MPI_ALLTOALLW and MPI_ALLTOALLX allow separate specification of count, displacement and datatype. In addition, to allow maximum flexibility, the displacement of blocks within the send and receive buffers is specified in bytes. In MPI_ALLTOALLW, these displacements are specified as integer arguments and in MPI_ALLTOALLX they are specified as address integer.

Rationale. The MPI_ALLTOALLW function generalizes several MPI functions by carefully selecting the input arguments. For example, by making all but one process have sendcounts[i] = 0, this achieves an MPI_SCATTERW function. MPI_ALLTOALLX allows the usage of MPI_BOTTOM as buffer argument and defining the different buffer location via the displacement arguments rather than only via different datatype arguments. (End of rationale.)

Add to page 165, after line 38:

MPI_ALLTOALLX(sendbuf, sendcounts, sdispls, sendtypes, recvbuf, 
                    recvcounts, rdispls, recvtypes, comm)
[ IN sendbuf]
starting address of send buffer (choice)
[ IN sendcounts]
integer array equal to the group size specifying the number of elements to send to each processor (array of integers)
[ IN sdispls]
integer array (of length group size). Entry j specifies the displacement in bytes (relative to sendbuf) from which to take the outgoing data destined for process j (array of integers)
[ IN sendtypes]
array of datatypes (of length group size). Entry j specifies the type of data to send to process j (array of handles)
[ OUT recvbuf]
address of receive buffer (choice)
[ IN recvcounts]
integer array equal to the group size specifying the number of elements that can be received from each processor (array of integers)
[ IN rdispls]
integer array (of length group size). Entry i specifies the displacement in bytes (relative to recvbuf) at which to place the incoming data from process i (array of integers)
[ IN recvtypes]
array of datatypes (of length group size). Entry i specifies the type of data received from process i (array of handles)
[ IN comm]
communicator (handle) 
      
      int MPI_Alltoallx(void *sendbuf, int sendcounts[], MPI_Aint sdispls[], 
      MPI_Datatype sendtypes[], void *recvbuf, int recvcounts[], MPI_Aint rdispls[], 
      MPI_Datatype recvtypes[], MPI_Comm comm)
      
      MPI_ALLTOALLx(SENDBUF, SENDCOUNTS, SDISPLS, SENDTYPES, RECVBUF, RECVCOUNTS, 
                    RDISPLS, RECVTYPES, COMM, IERROR) 
       SENDBUF(*), RECVBUF(*)
      INTEGER SENDCOUNTS(*), SENDTYPES(*), RECVCOUNTS(*), RECVTYPES(*), COMM, IERROR
      INTEGER (KIND=MPI_ADDRESS_KIND) SDISPLS(*), RDISPLS(*)
      
      void MPI::Comm::Alltoallx(const void* sendbuf, const int sendcounts[], 
      const MPI::Aint sdispls[], const MPI::Datatype sendtypes[], void* recvbuf, 
      const int recvcounts[], const MPI::Aint rdispls[], 
      const MPI::Datatype recvtypes[]) const = 0
Add to page 312, after line 37:
      
      int MPI_Alltoallx(void *sendbuf, int sendcounts[], MPI_Aint sdispls[], 
      MPI_Datatype sendtypes[], void *recvbuf, int recvcounts[], MPI_Aint rdispls[], 
      MPI_Datatype recvtypes[], MPI_Comm comm)
Add to page 322, after line 45:
      
      MPI_ALLTOALLx(SENDBUF, SENDCOUNTS, SDISPLS, SENDTYPES, RECVBUF, RECVCOUNTS, 
                    RDISPLS, RECVTYPES, COMM, IERROR) 
       SENDBUF(*), RECVBUF(*)
      INTEGER SENDCOUNTS(*), SENDTYPES(*), RECVCOUNTS(*), RECVTYPES(*), COMM, IERROR
      INTEGER (KIND=MPI_ADDRESS_KIND) SDISPLS(*), RDISPLS(*)
Add to page 335, after line 19:
      
      void MPI::Comm::Alltoallx(const void* sendbuf, const int sendcounts[], 
      const MPI::Aint sdispls[], const MPI::Datatype sendtypes[], void* recvbuf, 
      const int recvcounts[], const MPI::Aint rdispls[], 
      const MPI::Datatype recvtypes[]) const = 0
MPI_Type_size returns size as an int
This is a perenial erratum. However, with file types used for file views, it is not only possible but likely that datatypes will be (in fact, have been) constructed with a size that is greater than 2GB (range of a signed 32-bit int). Since we don't want to change MPI_Type_size, do we need another routine (and deprecate MPI_Type_size)?
MPI_UNPACK_EXTERNAL
Mail discussing


Proposed change

Page 79, Line 11 is 
MPI_UNPACK_EXTERNAL (datarep, inbuf, incount, datatype, outbuf, outsize,
position)
but should be 
MPI_UNPACK_EXTERNAL (datarep, inbuf, insize, position, outbuf, outcount,
datatype)
Additional C++ binding errors
Mail discussing
Proposed text
Page 337, line 31-32 reads 
bool MPI::Win::Get_attr(const MPI::Win&win, int win_keyval, 
              void* attribute_val) const
but should read 
bool MPI::Win::Get_attr(int win_keyval, void* attribute_val) const
MPI_Type_create_indexed_block description has two errors in the book MPI-The Complete Reference, Volume 1: The MPI Core, page 140, line 15.
Mail discussing

Note that this error does not appear in the MPI-2 standard (see page 40).

Are MPI_Win_wait and MPI_Win_post interchanged in the discussion of one-sided completion?
Mail discussing
The example of MPI_Scan in the MPI 1.1 Standard on page 128, line 11, has an extraneous root argument. That line should be 
    MPI_Scan( a, answer, 1, sspair, myOp, comm );
This could be added to section 3.2.10 (Minor Corrections) in the MPI 2 document.
Mail discussing
MPI_COMM_PARENT instead of MPI_COMM_GET_PARENT
Mail discussing

Page 179, lines 4-5 change

Thus, the names of MPI_COMM_WORLD, MPI_COMM_SELF, and MPI_COMM_PARENT will have the default of MPI_COMM_WORLD, MPI_COMM_SELF, and MPI_COMM_PARENT.
to
Thus, the names of MPI_COMM_WORLD, MPI_COMM_SELF, and the communicator returned by MPI_COMM_GET_PARENT (if not MPI_COMM_NULL) will have the default of MPI_COMM_WORLD, MPI_COMM_SELF, and MPI_COMM_PARENT.
Page 94, line 3-5, change
* The manager is represented as the process with rank 0 in (the remote * group of) MPI_COMM_PARENT. If the workers need to communicate among * themselves, they can use MPI_COMM_WORLD.
to
* The manager is represented as the process with rank 0 in (the remote * group of) the parent communicator. If the workers need to communicate among * themselves, they can use MPI_COMM_WORLD.
Error in MPI-1, Example 2.19
Mail discussing

This error is in MPI The Complete Reference. Is it in the standard as well?

Incorrect use of MPI_IN_PLACE in description of MPI_ALLGATHER and MPI_ALLGATHERV
Mail discussing

This item needs a proposed erratum.

Incorrect name for MPI_CANCEL
Mail discussing

MPI-2, section 8.2, page 172 mentions MPI_REQUEST_CANCEL; this should be MPI_CANCEL.

Missing newline in Fortran binding:
Change 
 \mpifbind{MPI\_FILE\_GET\_VIEW(FH, DISP, ETYPE, FILETYPE, DATAREP, IERROR)\fargs INTEGER FH, ETYPE, FILETYPE, IERROR \\ CHARACTER*(*) DATAREP, INTEGER(KIND=MPI\_OFFSET\_KIND) DISP}
to 
 \mpifbind{MPI\_FILE\_GET\_VIEW(FH, DISP, ETYPE, FILETYPE, DATAREP, IERROR)\fargs INTEGER FH, ETYPE, FILETYPE, IERROR \\ CHARACTER*(*) DATAREP\\ INTEGER(KIND=MPI\_OFFSET\_KIND) DISP}
in io-2.tex. See page 223, line 19. (replace the comma after the declaration of datarep)
Misspelled argument in Fortran binding
Change 
 \mpifbind{MPI\_TYPE\_CREATE\_HVECTOR(COUNT, BLOCKLENGTH, STIDE, OLDTYPE, NEWTYPE, IERROR)\fargs INTEGER COUNT, BLOCKLENGTH, OLDTYPE, NEWTYPE, IERROR\\INTEGER(KIND=MPI\_ADDRESS\_KIND) STRIDE}
to 
\mpifbind{MPI\_TYPE\_CREATE\_HVECTOR(COUNT, BLOCKLENGTH, STRIDE, OLDTYPE, NEWTYPE, IERROR)\fargs INTEGER COUNT, BLOCKLENGTH, OLDTYPE, NEWTYPE, IERROR\\INTEGER(KIND=MPI\_ADDRESS\_KIND) STRIDE}
in misc-2.tex (see page 66, line 26) (replace STIDE with STRIDE).
Error in MPI-1, Example 3.12
Mail discussing

The communicator argument is missing from the MPI communication calls.

Error in MPI-1, Example 3.34
Mail discussing

The variable base should be declared as MPI_Aint, not int.

Ambiguities

True ambiguities are places in the standard where there are several different readings of the standard with different semantics. An official resolution of these will require a vote by the MPI Forum, similar to the MPI 1.1 and MPI 1.2 versions of the MPI-1 Standard.

This section contains the discussion on these ambiguities and in cases where a consensus emerged, text has been proposed.

MPI_ALLOC_MEM behavior on failure
Mail discussing

Does MPI_ALLOC_MEM return a null pointer when a request for memory cannot be satisfied but a request for a smaller amount may work? The question is really if the user must set MPI_ERRORS_RETURN on MPI_COMM_WORLD before calling MPI_ALLOC_MEM if the user wants to handle "not enough memory for your request" errors.

MPI C++ Constants conflict with stdio
Mail discussing

Some names in the MPI Namespace in the C++ binding can conflict with C preprocessor names in standard include files. Examples include MPI:SEEK_SET} (conflicts with SEEK_SET in stdio.h).

C++ constructors for MPI objects
Mail discussing
Interlanguage use of Attributes
Mail discussing. See also Error in Example 4.13 in MPI-2
Error in Example 4.13 in MPI-2 (Use of Attributes in C and Fortran)
Mail discussing. See also Interlanguage use of Attributes.
Intercommunicator collective and datatypes
Mail discussing
Proposed text
Page 163, line 22 reads
Within each group, all processes provide the same recvcounts argument, and the sum of the recvcounts entries should be the same for the two groups.
but should read
Within each group, all processes provide the same recvcounts argument, and the sum of the recvcounts entries and datatype should specify the be the same type signature for the two groups.
What info keys can be set?
Mail discussing
Datatypes and MPI_PROBE
Mail discussing
MPI_PROCNULL and RMA Part 2
Mail discussing
Proposed text
Page 114, after line 4 (and after the lines added about MPI_PROC_NULL), add
After an RMA operations with rank MPI_PROC_NULL, it is still necessary to finish the RMA epoch with the synchronization method that has started the epoch.
Significance of non-root arguments to MPI_COMM_SPAWN
Mail discussing
Thread safety and collective communication
Mail discussing
MPI_LASTUSEDCODE
Mail discussing
const in C++ specification of predefined MPI objects (was just datatypes)
Mail discussing
The bindings for predefined types such as MPI::CHAR are const which was fine for MPI-1 but may be inappropriate in MPI-2 since datatypes have names and attributes, both of which can be set.

In addition to changes for MPI::Datatype, add these changes

Page 345, line 37:
Remove the const from const MPI::Op.
Page 346, line 20:
Remove the const from const MPI::Group.
Page 346, add after line 34:
Advice to implementors. If an implementation does not change the value of predefined handles while execution of MPI_Init, the implementation is free to define the predefined operation handles as const MPI::Op and the predefined group handle MPI::GROUP_EMPTY as const MPI::Group. Other predefined handles must not be "const" because they are allowed as INOUT argument in the MPI_COMM_SET_NAME/ATTR and MPI_TYPE_SET_NAME/ATTR routines. End of advice to implementors.

In the second ballot, we voted to remove const from MPI::Datatype on pages 343, 344, and 345.

LONG_LONG_INT and datatypes for MAXLOC/MINLOC
Mail discussing
Questions about Graph_create, Cart_crate, and Cart_coords
Mail discussing

The initial mail contains some comments that may be appropriate clarifications that do not change the standard.

Description of the send and receive count arguments to MPI_Alltoallv
Mail discussing

The description of the send and receive counts arguments could be interpreted as allowing the receive counts to be at least as large as required by the send count, rather than exactly matching the count as defined by the type signatures.

Does MPI_File_get_view return copies of the datatypes for the filetype and etype?
Mail discussing

The question really is "can (and must) the user free those datatypes"? For other MPI routines, the answer is always yes, but here the original datatype may be a predefined type, which may not be freed.

Is a group with no members always represented as MPI_GROUP_EMPTY, rather than a group that may be identical (in the sense of MPI_IDENT) to MPI_GROUP_EMPTY?
Mail discussing

Clarifications

Some questions sent to the forum do not reveal problems in the standard; instead, they concern items that are unclear or (as in the famous case of MPI_TYPE_SIZE) have been discussed at length by the MPI Forum, but without a summary of the discussion in the document.
Why no MPI_INPLACE for MPI_EXSCAN?
Mail discussing
Proposed text
Page 166, after line 47, add

Advice to users:
No in-place version is specified for MPI_EXSCAN because it isn't clear what this means for the process for rank zero.
End of advice to users.

MPI_GET_PROCESSOR_NAME and Fortran
Mail discussing
No proposed text. The consensus was that the the standard is precise enough and no clarification is needed. Note that at least one implementation does not implement this correctly.
Interpretation of user defined datarep
Mail discussing
Shared File Pointers
Mail discussing
Attribute copying in multithreaded programs
Mail discussing
Overlapping buffers in collective communications
Mail discussing
MPI_Abort
Mail discussing
MPI_Type_create_f90_real etc.
Mail discussing
MPI_MODE_RDONLY, MPI_MODE_RDWR, MPI_MODE_WRONLY
Is it an error to specify more than one of these?
MPI_AINT, MPI_OFFSET
Is there an MPI datatype that can be used to send and receive these values? This needed by applications working with MPI windows and files.
MPI_Offset and MPI_Aint
Can these really be different?
MPI_File_get_info
Add text stating that the return value can be null.
MPI_File_set_view
Does the info passed to MPI_File_set_view replace all of the previous info keys?
Error handler for multiple completions
Mail discussing

The text added in MPI 1.1 on the error return for MPI_Waitall etc. is written as if the only error handler is MPI_ERRORS_RETURN.

MPI_FINALIZE in MPI-2 (with spawn)
Mail discussing
Reporting invalid handles provided to handle conversion functions
Mail discussing

No changes needed.

Blocklengths of zero in MPI_TYPE_STRUCT
Mail discussing

Blocklengths of zero are allowed. Do we need to add a statement to this effect?

MPI_IN_PLACE for MPI_Reduce_scatter
Mail discussing
Proposed text to replace lines 16-20, pg 163
The "in place" option for intracommunicators is specified by passing MPI_IN_PLACE in the sendbuf argument. In this case, on each process, the input data is taken from recvbuf. Process i gets the ith segment of the result, and it is stored at the location corresponding to segment i in recvbuf.
Block lengths of zero in MPI Datatypes
Mai discussing A deeper discussion of the implications of zero-length blocks in MPI datatypes.

Tracking Evolution of Language Standards

New C Datatypes
Mail discussing

The ISO/IEC Standard for C has added a number of new required and optional datatypes, such as int32_t and _Bool.

IEEE Floating Point Behavior
Mail discussing

Other Issues

Waiting for processes to exit
Mail discussing

In brief, in some cases when using dynamic processes, an application may need to know when a process, recently disconnected with MPI_Comm_disconnect, has exited. There is no easy way within MPI to do this since MPI_Comm_disconnect doesn't wait for the process to exit (and it shouldn't, of course).

Improving MPI_Reduce_scatter
Mail discussing

This proposes an extension to MPI to add a constant block-size version of MPI_Reduce_scatter, much as MPI-2 added MPI_Type_create_indexed_block. This allows implementations to optimize the implementation of this routine. Several uses of MPI_Reduce_scatter with constant block sizes have recently been discussed at the Euro PVMMPI meetings.

Possible error in RMA example
Mail discussing

The example appears to make use of data before the necessary MPI_Win_complete is called to end the exposure epoch.

Describing messages larger than 2GB
Mail discussing

The use of integers (and even address-sized integers) in MPI routines such as the point-to-point routines and datatype creation can limit the (at least with the natural choice of arguments) size of message that may be sent. Some MPI users now want to send messages greater than 2 GB; the use of MPI datatypes to describe file layouts can also run into trouble on 32-bit systems.

Nonblocking connect and accept
Mail discussing

This proposes a form of non-blocking connect and accept.