Introduction

This page contains information and pointers to discussions about MPI Errata Items that have been adopted. No part of this document is official. See the MPI Forum web site for official errata.

Comments on the MPI standard should be mailed to mpi-core@mcs.anl.gov. 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:

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.
MPI_MAX_NAME_STRING
Mail discussing
Proposed text
Page 60, line 1 reads
char name[MPI_MAX_NAME_STRING];
but should read
char name[MPI_MAX_OBJECT_NAME];
Converting handlers for MPI_Errhandler
No mail, but MPI_Errhandler_f2c and MPI_Errhandler_c2f are missing from the list of functions to convert handlers.
Proposed text
Page 51, after line 43, add
MPI_Errhandler MPI_Errhandler_f2c(MPI_Fint errhandler)
MPI_Fint MPI_Errhandler_c2f(MPI_Errhandler errhandler)

These were overlooked.

MPI_LONG_LONG_INT and MPI_LONG_LONG
Mail discussing
Proposed text
Page 251, Line 18 reads 
        MPI_LONG_LONG             8
but should read 
        MPI_LONG_LONG_INT         8
In addition, the type MPI_LONG_LONG should be added as an optional type; it is a synonym for MPI_LONG_LONG_INT.
MPI_MODE_SEQUENTIAL
Mail discussing
Proposed text
Page 230, after line 17, change
If MPI_MODE_SEQUENTIAL mode was specified when the file was opened, it is erroneous to call the routines in this section.
to
If MPI_MODE_SEQUENTIAL mode was specified when the file was opened, it is erroneous to call the routines in this section, with the exception of MPI_FILE_GET_BYTE_OFFSET.
Call by reference in C++ example
Mail discussing
Proposed text
Page 53, line 7, change
void cpp_lib_call(MPI::Comm& cpp_comm);
to 
void cpp_lib_call(MPI::Comm cpp_comm);
Miscellaneous minor C++ problesm
Mail discussing
Proposed text
Page 116, line 31, reads
void MPI::Win::Get(const void *origin_addr, int origin_count, const MPI::Datatype& origin_datatype, int target_rank, MPI::Aint target_disp, int target_count, const MPI::Datatype& target_datatype) const
but should read
void MPI::Win::Get(void *origin_addr, int origin_count, const MPI::Datatype& origin_datatype, int target_rank, MPI::Aint target_disp, int target_count, const MPI::Datatype& target_datatype) const

Proposed text
Page 204, line 30 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

Proposed text
Page 346, line 16 reads
// Type: MPI::Errhandler
but should read 
// Type: const MPI::Errhandler

Proposed text
Page 253, lines 22-24 read
typedef MPI::Datarep_conversion_function(void* userbuf, MPI::Datatype& datatype, int count, void* filebuf, MPI::Offset position, void* extra_state);

but should read

typedef void MPI::Datarep_conversion_function(void* userbuf, MPI::Datatype& datatype, int count, void* filebuf, MPI::Offset position, void* extra_state);

Additional C++ binding errors
Mail discussing
Proposed text
Page 253, line 4 reads 
typedef MPI::Datarep_extent_function(const MPI::Datatype& datatype,
but should read 
typedef void MPI::Datarep_extent_function(const MPI::Datatype& datatype,

Page 334, line 22 reads 

void MPI::Win::Get(const void *origin_addr, int origin_count, const
but should read 
void MPI::Win::Get(void *origin_addr, int origin_count, const

Page 341, line 18 reads 

typedef MPI::Datarep_conversion_function(void* userbuf,
but should read 
typedef void MPI::Datarep_conversion_function(void* userbuf,

Page 341, line 22 reads 

typedef MPI::Datarep_extent_function(const MPI::Datatype& Datatype,
but should read 
typedef void MPI::Datarep_extent_function(const MPI::Datatype& Datatype,

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.

Contiguous Datatypes of size 0
Mail discussing
Proposed text
This refers to MPI-1, and so would be added to the Miscellany chapter. Add the text to page 36, after line 3:

3.2.11 MPI_GET_COUNT with zero-length datatypes

The value returned as the count argument of MPI_Get_count for a datatype of length zero where zero bytes have been transferred is zero. If the number of bytes transfered is greater than zero, MPI_UNDEFINED is returned.

Rationale:
Zero-length datatypes may be created in a number of cases. In MPI-2, an important case is MPI_TYPE_CREATE_DARRAY, where the definition of the particular darry results in an empty block on some MPI process. Programs written in an SPMD style will not check for this special case and may want to use MPI_GET_COUNT to check the status.
End of rationale.

MPI_PROC_NULL and MPI_GROUP_TRANSLATE_RANKS
Mail discussing
Proposed text
Add to page 36, after 3.2.11 (above):

3.2.12 MPI_GROUP_TRANSLATE_RANKS and MPI_PROC_NULL

MPI_PROC_NULL is a valid rank for input to MPI_GROUP_TRANSLATE_RANKS, which returns MPI_PROC_NULL as the translated rank.
Freeing Error Handlers
Mail discussing
Proposed text
Page 61, after line 36. Add the following
MPI_ERRHANDLER_GET and MPI_{COMM,WIN,FILE}_GET_ERRHANDLER behave as if a new error handler object is created. That is, once the error handler is no longer needed, MPI_ERRHANDLER_FREE should be called with the error handler returned from MPI_ERRHANDLER_GET or MPI_{COMM,WIN,FILE}_GET_ERRHANDLER to mark the error handler for deallocation. This provides behavior similar to that of MPI_COMM_GROUP and MPI_GROUP_FREE.

Begin Rationale: This case was overlooked in the MPI-1 document. It ensures that error handler objects behave with the same reference-count semantics of other MPI objects. End of Rationale.

MPI_PROCNULL and RMA
Mail discussing
Proposed text
Page 114, after line 4, add MPI_PROC_NULL is a valid target rank in the MPI RMA calls MPI_ACCUMULATE, MPI_GET, and MPI_PUT. The effect is the same as for MPI_PROC_NULL in MPI point-to-point communication.
MPI_REPLACE and other MPI collective computation
Mail discussing
Proposed text
Add to page 120, after line 13:
MPI_REPLACE, like the other predefined operations, is defined only for the predefined MPI datatypes.
The rationale for this is that, for consistency, MPI_REPLACE should have the same limitations as the other operations. Extending it to all datatypes doesn't provide any real benefit.
Counter argument: MPI_REPLACE was intended for use with MPI_ACCUMULATE where it does provide a benefit when used with other datatypes (providing a ``overlappable'' MPI_PUT).
Intercommunicator collective and datatypes
Mail discussing
Proposed text
Page 162, line 48 reads
Both groups should provide the same count value.
but should read
Both groups should provide count and datatype arguments that specify the same type signature.
MPI_DISPLACEMENT_CURRENT
Mail discussing
Proposed text
Page 221, after line 40, add
MPI_DISPLACEMENT_CURRENT is invalid unless the amode for the file has MPI_MODE_SEQUENTIAL set.

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.
Datatype for sending data packed with MPI_PACK_EXTERNAL
Mail discussing
Proposed text On Page 78, after line 27, add:
MPI_BYTE should be used to send and receive data that is packed using MPI_PACK_EXTERNAL. Rationale: MPI_PACK_EXTERNAL specifies that there is no header on the message and further specifies the exact format of the data. Since MPI_PACK may (and is allowed to) use a header, the datatype MPI_PACKED cannot be used for data packed with MPI_PACK_EXTERNAL.
Description of Collective Operations
The description of the collective operations in the MPI Standard often uses the blocking MPI point-to-point operations. This serves to illustrate what data is sent to which process. However, as MPI programs, they are often unsafe and may deadlock.

Proposed text On page 93 after line 48, add
Many of the descriptions of the collective routines provide illustrations in terms of blocking MPI point-to-point routines. These are intended solely to indicate what data is sent or received by what process. Many of these examples are not correct MPI programs; for purposes of simplicity, they often assume infinite buffering.
Keyvals are related to particular MPI opaque objects
The text associated with MPI_ERRHANDLER advises implementors to raise an error if an error handler associated with one type (e.g., a communicator) is used with another type (e.g., a window). The same reasons hold for keyvals because the attribute copy and delete functions have arguments that are specific to the particular MPI opaque object. No change to the text is really required (since the text under error handler is only an advice to implementors), but for completeness, similar text should be added.
Proposed text On Page 199, after line 11, add:
Advice to implementors. High quality implementations should raise an error when a keyval that was created by a call to MPI_XXX_CREATE_KEYVAL is used with an object of the wrong type with a call to MPI_YYY_GET_ATTR, MPI_YYY_SET_ATTR, MPI_YYY_DELETE_ATTR, or MPI_YYY_FREE_KEYVAL. To do so, it is necessary to maintain, with each keyval, information on the type of the associated user function. ( End of advice to implementors.)

Tracking Evolution of Language Standards