[MPI3 Fortran] MPI draft 2011-04-21

[Rasmussen, Craig E]

Rolf,

I've finished with proposal writing madness and I've now had time to review the MPI draft 2011-04-21.  Please find detailed comments below:

-craig



--------------------------------

Pg 543 2nd paragraph:  There is a discussion of MPI_SUBARRAYS_SUPPORTED here.  I think we should also add an advice to implementers regarding MPI_SUBARRAYS_SUPPORTED.  This advice should include information about the need to copy possibly non-contiguous regions of memory specified by an array descriptor.

Pg 543, line 26: insert "may" ==> "While these may cause few problems" because the original MPI Fortran bindings violate the Fortran standard and compilers are becoming more aggressive at catching these violations.

Pg 543, line 31: The list is also inconsistent with implicit interfaces ("Fortran 77" style) as well as explicit interfaces.  This discussion gives the wrong impression that Fortran 90 is inferior to Fortran 77.

Pg 543, line 45:  These named "constants" are an implementation detail and I don't understand why this is more than advice to implementors.

Pg 544, line 4:  MPI_ALLOC_MEM should be defined so that the language interoperability features in F2003 can be used to associate the allocated memory with a Fortran variable.

Pg 544, line 36: With combinations of choice arguments it is impractical to provide overloaded functions for all argument combinations.

Pg 544, line 40: Replace sentence fragment with: "the following code fragment is technically invalid and may generate ..."

Pg 545: line 6 and 11: DIMENSION(..) in mpi_f08 allows scalar arguments for choice buffers.  Replace "USE mpi_f08" with "USE mpi"

Pg 545, line 15: Replace original phrase with "compiler warnings are not expected (but may occur) unless ..."

Pg 545, line 19: Delete "in" in the phrase "describe in Fortran subarrays"

Pg 545, line 36: Replace "compiled code must not" with "compiled code will not"

Pg 545, line 29: Delete ", ..., s(96)" as there are only 3 elements send in the MPI_Isend call.

Pg 545, line 41: I would put the phase "as if" in italics

Pg 546, lines 16 and 20:  The "_NOT_" in MPI_SUBARRAYS_NOT_SUPPORTED is in a extra large font.

Pg 546, line 29:  The discussion related to the phrase "Most compilers ensure ..." is true (I think, although I haven't seen a compiler do otherwise) but I believe if the interfaces are defined with the BIND(C) attribute that the compiler will be forced to make a copy.

Pg 546, footnote 1: Replace "Fortran standards are worded" with "Fortran standard is worded"

Pg 547, line 24: Replace "Some compilers make a copy of some scalar" with "A compiler may make a copy of scalar"

Pg 547, line 28: Insert "real :: a" in the example to make the scalar argument clear

Pg 548, line 14: Replace "an possibly" with "a possibly"

Pg 548, paragraph starting at line 25:  I don't think the discussion regarding constants/parameters is true as because an implementor can directly link to C variables with BIND(C), e.g., 

       type(MPI_Group),      protected, bind(C, name="ompi_f08_mpi_group_null")      :: MPI_GROUP_NULL


Pg 548, line 43 and example on page 549:  I think "sequence" should be "SEQUENCE" to be consistent.  However I don't agree with the entire argument about sequence types.  The example on page 549 uses displacements based on calls to MPI_GET_ADDRESS.  I'm probably missing something because I think this should work irrespective of the use of SEQUENCE because the MPI data type is constructed with calls to MPI_GET_ADDRESS.  However, the type will not be interoperable across C and Fortran because the struct is not declared with BIND(C).

Pg 550 (and elsewhere):  I would use "Code movement" rather than "Code movements"  and "Data movement" rather than "Data movements", especially as data is plural anyway.

Pg 550, line 37: Replace "or COMMON block" with "or a COMMON block"

Pg 551,  line 17: Don't understand where "send(*addr)" comes from.  Shouldn't it be MPI_Isend or MPI_Wait or something similar?

Pg 551, line 27:  I would insert "by the compiler" at the end of the sentence.

Pg 551, line 31:  I don't understand why MPI_BOTTOM and derived MPI datatypes are special, we should talk about this a the next forum meeting.

Pg 552, two examples:  These examples remind me that we need to carefully think where the TARGET attribute should/must be used in a valid MPI program.

Pg 552, line 43: Replace this line with "operations in which MPI_BOTTOM is used or datatype handles that combine several variables are used:

Pg 553, line 4: Replace "can solve" with "may solve"

Pg 553, line 6: Insert something like "MPI_F_SYNC_REG and the use of module data" are not guaranteed to work by the Fortran standard, though will likely work on most compilers.

Pg 554, first paragraph: MPI_F_SYNC_REG should be made BIND(C) to keep Fortran from very aggressive optimizations.

Pg 555, line 16+: Remove discussion of DD.  Compiler more likely to optimize user function that something MPI vendor writes and tests.

Pg 556, line 1:  Replace "(evil)" with :(poorly performing)"

Pg 556:  I would move Fortran language attribute (VOLATILE and ASYNCHRONOUS) usage discussion above what are essentially hacks that are outside of the language (MPI_F_SYNC_REG and Module Data).

Pg 556, line 14:  I would add a discussion of the TARGET attribute and its usage

Pg 556, line 17: Replace "modify temporarily" with "temporarily modify"

Pg 556, line 44: Replace "may also occurs" with "may also occur"

Pg 557, line 19: Replace "of a local memory" with "of a separate memory storage area"

Pg 557, line 34: Should "the window buffer" be "the MPI window buffer"?  I not sure what window references.  Also, is RMA correct?

Pg 557, line 45: "Said this" should probably be replaced with "This said" or "Thus"

Pg 558, lines 1-3:  ASYNCHRONOUS may actually be fixed at WG5 so lines 2-3 may in fact turn out to be an incorrect statement.

Pg 558, lines 8-18:  ASYNCHRONOUS is used here where the discussion is about VOLATILE

Pg 559, lines 47-48:  Are there really any "Fortran 77" compilers around?  The Fortran standard accepts ! as starting a comment for both fixed- and free-form formatted files.

Pg 563, line 6: should be reworded with something like "BIND(C) allows vendors to implement the ..."

Pg 563, line 41: I would replace "memorize" with "store"

Pg 563, last paragraph: This is not guaranteed by the Fortran standard.

Pg 564, 4th bullet: I disagree with the 4th bullet as I believe it ultimately breaks the Fortran standard.  How can two different types (INTEGER and a derived-type handle) both be valid to the same interface?

Pg 564, lines 34-38:  Disagree with any discussion of additional compiler support needed beyond TR 29113.  If this is related to SEQUENCE and BIND(C) I don't think it will ever happen (I don't think it will get a single yes vote from the Fortran committee) and would not be in the standard for 3-5 years anyway.  See also SEQUENCE discussion in last paragraph on this page.

Pg 564, line 41:  I suggest that CHARACTER*(*) be replaced with more modern usage.

Pg 565: Regarding MPI_F_SYNC_REG: In advice to implementors this function should be made BIND(C) to, perhaps, disallow aggressive optimizations.