The Embiggenment ("BigCount") -- Errata

[tonyskjellum]

Problem

Fixes several small issues with the accepted large-count API (cf, Ticket #137 )

Proposal

Fix small issues as specified in the changes to text, mentioned next.

Changes to the Text

0. the change bar latex macros have been removed

1. change all new function extensions from _l to _c and the text "

• an underscore followed by a lower-case L " has been removed, where
  used

2. addition of the following sentence in Section 2.5.8: "Even though
   the \type{MPI_Count} type is large enough to encode address
   locations, \type{MPI_Count} type shall not be used to represent
   an \mpitermni{absolute address}\mpitermindex{addresses!absolute}."

3. delete the following sentence that was repeated: "The support
   for large count and displacement in Fortran is available when using
   newer \MPI/ Fortran bindings \code{(USE mpi_f08)}."

4. embiggen MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS

5. change error class from MPI_ERR_VALUE_TOO_LARGE to MPI_ERR_TYPE
   for functions MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS

6. addition of separate MPI_Op_create_c and MPI_Register_datarep_c functions for F08 bindings

The following text has been added to the I/O chapter to indicate this feature:

\mpifunc{MPI_Datarep_conversion_function} also supports large
count types in separate additional \MPI/ procedures in C (suffixed
with the ``_c'') and interface polymorphism in Fortran when using
\code{USE mpi_f08}.

The following text has been added to the collective chapter to indicate this feature:

When calling any reduction or prefix scan \MPI/ procedure with a
user-defined MPI operator, the type of the \mpiarg{count} parameter
in the call to the reduction or prefix scan \MPI/ procedure does
not need to be identical to the type of the \mpiarg{len} parameter
in the user function associated with the user-defined \MPI/ operator.
If the \mpiarg{count} parameter has a type of \ctype{int} in C or
\ftype{INTEGER} in Fortran and the \mpiarg{len} parameter has a
type of \type{MPI_COUNT}, then \MPI/ will perform the appropriate
widening type conversion of the \mpiarg{len} parameter. If the
\mpiarg{count} parameter has a type of \type{MPI_COUNT} and the
\mpiarg{len} parameter has a type of \ctype{int} in C or \ftype{INTEGER}
in Fortran, then \MPI/ will perform the appropriate narrowing type
conversion of the \mpiarg{len} parameter. If this narrowing
conversion would result in truncation of the \mpiarg{len} value,
then \MPI/ will call the user function multiple times with a sequence of
values for \mpiarg{len} that sum to the value of \mpiarg{count}.

We also added this text to the collective chapter:
\mpifunc{MPI_User_function} also supports large count types in
separate additional \MPI/ procedures in C (suffixed with the ``_c'')
and interface polymorphism in Fortran when using \code{USE mpi_f08}.

7. following text changes in Section 18.2:

(a) replace "The following were used prior to MPI-4.0:" with "The
following types, which were used prior to MPI-4.0, have been deemed
too small to hold values that applications wish to use:" and remove
the sentence "These types have been deemed too small to hold values
that applications wish to use." in the next paragraph

(b) addition of "(e.g., in constructors of MPI datatypes that can be used with files)"
to the end of third bullet

(c) addition of the following new text (with any variations): For
the large count versions of three datatype constructors,
MPI_TYPE_CREATE_HINDEXED, MPI_TYPE_CREATE_HINDEXED_BLOCK, and
MPI_TYPE_CREATE_STRUCT, absolute addresses shall not be used to
specify byte displacements since the parameter is of type MPI_COUNT
instead of type MPI_AINT (see Section 2.5.8).

We added this text to the Datatypes chapter:
For the large count versions of three datatype constructors with explicit addresses,
\mpifunc{MPI_TYPE_CREATE_HINDEXED}, \mpifunc{MPI_TYPE_CREATE_HINDEXED_BLOCK}, and
\mpifunc{MPI_TYPE_CREATE_STRUCT}, absolute addresses shall not be used to
specify byte displacements since the parameter is of type MPI_COUNT
instead of type \type{MPI_AINT}.

(d) addition of "MPI_Offset for parameters that represent byte displacement in files, " in the C bindings description

(e) addition of "INTEGER(KIND=MPI_OFFSET_KIND) for parameters that
represent byte displacement in files, " in the Fortran bindings
description

8. Addition of the text to add an exception for the two explicit "_c" functions in F08:

It is erroneous to directly invoke the "_c" specific procedures in
the Fortran mpi_f08 module with the exception of the following
procedures: MPI_Op_create_c and MPI_Register_datarep_c.

Impact on Implementations

Clarifies certain aspects of implementation APIs, but we are making these pre-standard.

Impact on Users

None, part of new standardization correction.

References

Original ticket : #137
PR: https://github.com/mpi-forum/mpi-standard/pull/268
PDF: mpi40-report-ticket137-711c32c-6Nov2020.pdf
Annotated PDF: mpi40-report-ticket137-711c32c-6Nov2020-highlighted.pdf

[RolfRabenseifner]

RC40 Sect. 6.9.5, page 230, line 5 reads

MPI_REDUCE_LOCAL. The user-defined ...

but should read

MPI_REDUCE_LOCAL. In the case of Fortran mpi_f08, the large count version needs to be called explicitely as MPI_Op_create_c (i.e., with _c) because interface polymorphism cannot be used to differentiate between the two different user callback prototypes with their different type signatures. The use-defined ..

[dholmes-epcc-ed-ac-uk]

Minor tweaks:

MPI_REDUCE_LOCAL. In the case of Fortran mpi_f08, the large count version shall be called explicitly as \mpifunc{MPI_Op_create_c} (i.e., with the \mpicode{_c} suffix) because interface polymorphism cannot be used to differentiate between the two different user callback prototypes with their different type signatures. The user-defined ..

[wesbland]

2020-12-08 No-No vote results

Yes	No	Abstain	Missed	Result
29	0	1	0	Passed