MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem #388

mpiforumbot · 2016-07-24T20:48:10Z

Originally by RolfRabenseifner on 2013-08-13 07:25:21 -0500

Description

MPI-3.0 has some inconsistencies in the new Fortran bindings, which must be corrected
with MPI-3.0 errata.

The MPI-3.0 mpi_f08 module was based on the assumption that Fortran LOGICAL
is interoperable with C. This is not the case in Fortran 2008 nor in the addendum TS 29113.
With the proposed errata, it is no more required that LOGICAL is interoperable.

Extended Scope

MPI-3.0 errata.

History

A first draft was discussed in ticket #364. This draft is now withdrawn.

Proposed Solution (as MPI-3.0 errata)

See attached pdf file:[[BR]]
attachment:errata-30-ticket388-2013-08-27.pdf
[[BR]] This version was proposed two weeks before the Madrid Sep. 2013 meeting.

The attachment:ticket388-BillLong-2013-08-14-demo.tar.gz
contains an implementation example together with an example
on using the PMPI interface.

Description

MPI-3.0 has some inconsistencies in the new Fortran bindings, which must be corrected
with MPI-3.0 errata.

The MPI-3.0 mpi_f08 module was based on the assumption that Fortran LOGICAL
is interoperable with C. This is not the case in Fortran 2008 nor in the addendum TS 29113.
With the proposed errata, it is no more required that LOGICAL is interoperable.

Extended Scope

MPI-3.0 errata.

History

A first draft was discussed in ticket #364. This draft is now withdrawn.

Proposed Solution (as MPI-3.0 errata)

See attached pdf file:[[BR]]
attachment:errata-30-ticket388-2013-09-12.pdf
[[BR]] This version includes the latest ticket-0 changes
from the formal reading at the Madrid Sep. 2013 meeting.

The attachment:ticket388-BillLong-2013-08-14-demo.tar.gz
contains an implementation example together with an example
on using the PMPI interface.

Preliminary versions have been:

attachment:errata-30-ticket388-2013-08-27.pdf
[[BR]] This version was proposed two weeks before the Madrid Sep. 2013 meeting.
attachment:errata-30-ticket388-2013-09-05.pdf
[[BR]]Based on the reviews, ticket-0-editorial changes were added before the reading of the ticket.
[[BR]]This version is proposed for the reading in Madrid.

Impact on Implementations

Because these changes are in within the MPI mpi_f08 interfaces,
these errata must be applied before the new interfaces are implemented.
For the preliminary implementation without TS29113, the only impact is for the
definition of callback functions and the predefined callback functions.
Same is valid for the mpi module and mpif.h, but only if TS29113 is also
applied for those Fortran support methods.

Impact on Applications / Users

When using the described MPI callback routine interfaces, the user should be aware of these
errata (i.e., the function definitions are without BIND(C)), otherwise the compiler may return an error message.

Alternative Solutions

None.

Entry for the Change Log

In subsection "Fixes to Errata in Previous Versions of MPI":

MPI-3.0 Chapters 3-17, Annex A.3 on page 707, and Example 5.21 on page 187,
and MPI- Chapters <3-17>, Annex <A.3>, and Example <5.21>.[[BR]]
Within the mpi_f08 Fortran support method, BIND(C) was removed from all SUBROUTINE, FUNCTION, and ABSTRACT INTERFACE definitions.

MPI-3.0 Section 17.1.4 on page 603, and MPI- Section <17.1.4> on page xxx.[[BR]]
The advice to implementors at the end of the section was rwritten and moved into the
following section.

MPI-3.0 Sections 8.2 (MPI_ALLOC_MEM and MPI_ALLOC_MEM_CPTR),
11.2.2 (MPI_WIN_ALLOCATE and MPI_WIN_ALLOCATE_CPTR),
11.2.3 (MPI_WIN_ALLOCATE_SHARED and MPI_WIN_ALLOCATE_SHARED_CPTR),
11.2.3 (MPI_WIN_SHARED_QUERY and MPI_WIN_SHARED_QUERY_CPTR),
14.2.1 and 14.2.7 (Profiling interface),
and corresponding sections in MPI-.[[BR]]
The linker name concept was substituted by defining specific procedure names.

MPI-3.0 Section 17.1.5 on page 605, and MPI- Section <17.1.5> on page xxx.[[BR]]
The section was fully rewritten.
The linker name concept was substituted by defining specific procedure names.

MPI-3.0 Section 17.1.6 on page 611, and MPI- Section <17.1.6> on page xxx.[[BR]]
The requirements on BIND(C) procedure interfaces are removed.

Voting category

This is a simple correction of an inconsistency.[[BR]]
Therefore single reading+vote is recommended.

Impact on Implementations

Because these changes are in within the MPI mpi_f08 interfaces,
these errata must be applied before the new interfaces are implemented.
For the preliminary implementation without TS29113, the only impact is for the
definition of callback functions and the predefined callback functions.
Same is valid for the mpi module and mpif.h, but only if TS29113 is also
applied for those Fortran support methods.

Impact on Applications / Users

When using the described MPI callback routine interfaces, the user should be aware of these
errata (i.e., the function definitions are without BIND(C)), otherwise the compiler may return an error message.

Alternative Solutions

None.

Entry for the Change Log

In subsection "Fixes to Errata in Previous Versions of MPI":

MPI-3.0 Chapters 3-17, Annex A.3 on page 707, and Example 5.21 on page 187,
and MPI- Chapters <3-17>, Annex <A.3>, and Example <5.21>.[[BR]]
Within the mpi_f08 Fortran support method, BIND(C) was removed from all SUBROUTINE, FUNCTION, and ABSTRACT INTERFACE definitions.

MPI-3.0 Section 17.1.4 on page 603, and MPI- Section <17.1.4> on page xxx.[[BR]]
The advice to implementors at the end of the section was rwritten and moved into the
following section.

MPI-3.0 Sections 8.2 (MPI_ALLOC_MEM and MPI_ALLOC_MEM_CPTR),
11.2.2 (MPI_WIN_ALLOCATE and MPI_WIN_ALLOCATE_CPTR),
11.2.3 (MPI_WIN_ALLOCATE_SHARED and MPI_WIN_ALLOCATE_SHARED_CPTR),
11.2.3 (MPI_WIN_SHARED_QUERY and MPI_WIN_SHARED_QUERY_CPTR),
14.2.1 and 14.2.7 (Profiling interface),
and corresponding sections in MPI-.[[BR]]
The linker name concept was substituted by defining specific procedure names.

MPI-3.0 Section 17.1.5 on page 605, and MPI- Section <17.1.5> on page xxx.[[BR]]
The section was fully rewritten.
The linker name concept was substituted by defining specific procedure names.

MPI-3.0 Section 17.1.6 on page 611, and MPI- Section <17.1.6> on page xxx.[[BR]]
The requirements on BIND(C) procedure interfaces are removed.

Voting category

This is a simple correction of an inconsistency.[[BR]]
Therefore single reading+vote is recommended.

mpiforumbot · 2016-07-24T20:48:15Z

Originally by RolfRabenseifner on 2013-08-13 07:41:07 -0500

Link to pdf file added to the Solution section.

mpiforumbot · 2016-07-24T20:48:16Z

Originally by RolfRabenseifner on 2013-08-13 08:01:22 -0500

First Change-log item updated.

mpiforumbot · 2016-07-24T20:48:17Z

Originally by RolfRabenseifner on 2013-08-13 08:48:04 -0500

Name of attachment changed from 364 to 388 to reflect new ticket number.

mpiforumbot · 2016-07-24T20:48:17Z

Originally by RolfRabenseifner on 2013-08-16 08:53:28 -0500

I added implmentation examples from Bill Long.
See also README.txt within attachment:ticket388-BillLong-2013-08-14-demo.tar.gz

mpiforumbot · 2016-07-24T20:48:18Z

Originally by RolfRabenseifner on 2013-08-16 23:19:54 -0500

Attachment added: ticket388-BillLong-2013-08-14-demo.tar.gz (96.9 KiB)
Example to implement Fortran wrappers and how to use the PMPI interface

mpiforumbot · 2016-07-24T20:48:18Z

Originally by RolfRabenseifner on 2013-08-16 23:41:18 -0500

The new version attachment:errata-30-ticket388-2013-08-16.pdf contains on page 8 line 41 - page 9 line 16 an additional advice to users (compared to the old version from 2013-08-13) that explains how to intercept a Fortran MPI call with a profiling routine.

The README.txt in the attachment:ticket388-BillLong-2013-08-14-demo.tar.gz was updated.

mpiforumbot · 2016-07-24T20:48:19Z

Originally by RolfRabenseifner on 2013-08-19 05:36:11 -0500

Typo corrections in the attached pdf file.

mpiforumbot · 2016-07-24T20:48:20Z

Originally by RolfRabenseifner on 2013-08-19 11:30:31 -0500

Typo corrections

mpiforumbot · 2016-07-24T20:48:21Z

Originally by rasmus on 2013-08-21 01:39:00 -0500

The changes made in this errata are required because LOGICAL variables (of default kind) are not directly interoperable with C. As a consequence, it was decided to remove BIND(C) from the interface specification of all MPI procedures. These changes --- and others related to the use of specific procedure names rather than linker symbol names --- substantially shorten and simplify section 17.1.5. Users of the MPI profiling interface are encouraged to intercept MPI calls in Fortran rather than in C (using compiler dependent linker symbol names).

mpiforumbot · 2016-07-24T20:48:21Z

Originally by RolfRabenseifner on 2013-08-21 01:57:30 -0500

To follow-up Craig's review:

The proposed solution is

needed and correct (i.e., solves the detected problem),
verified (i.e., the attached example implementation works and can be used for profiling as expected),
is complete (i.e., corrects all locations in the MPI standard that must be corrected),
and the wording was checked and corrected in detail by Jeff Squyres and Craig Rasmussen, and also parts by Bill Long.

mpiforumbot · 2016-07-24T20:48:22Z

Originally by RolfRabenseifner on 2013-08-22 04:13:22 -0500

Small ticket 0 changes from previous version to new pdf.

In the description of this ticket, only the date of the pdf was changed
(2013-08-19 into 2013-08-22)

mpiforumbot · 2016-07-24T20:48:23Z

Originally by jsquyres on 2013-08-22 08:54:30 -0500

I have reviewed the 2013-08-22 PDF file and it looks good to me.

mpiforumbot · 2016-07-24T20:48:23Z

Originally by rasmus on 2013-08-22 12:44:06 -0500

I've reviewed the 2013-08-22 PDF file and the changes improve the document. I find that the entire errata meets the goal of fixing the problems found with the non-interoperability of Fortran LOGICAL variables with C. The changes in the errata actually make the MPI-3 standard simpler and are an improvement over the original.

However, I would suggest one small change.

I have a preference for,

  my_rename => MPI_Isend_f08ts

over

  my_noname => MPI_Isend_f08ts

on 9:5. The reasoning is that this syntax changes the name of MPI_Isend_f08ts in the current scoping unit. It doesn't actually make the name disappear (as noname suggests to me). The use of my_rename hints that a rename is occurring.

mpiforumbot · 2016-07-24T20:53:24Z

Originally by longb on 2013-08-22 17:34:06 -0500

I've reviewed the 2013-08-22 PDF file. The proposed Errata fixes the MPI 3.0 problems in the Fortran interface related to BIND(C) and the Fortran tools interface. This fix is needed. I believe further improvements in the MPI Fortran interface are possible and worth considering, but those are beyond the scope of an Errata. This Errata provides the minimal changes needed to correct the existing problems.

I do have two minor comments on the text:

I assume the first sentence "The known corrections to MPI-3.0 are listed in this document." is intended to apply only to the corrections regarding the Fortran interface and not ALL corrections to MPI-3.0.
Page 6, line 25, "its" should be "their".

mpiforumbot · 2016-07-24T20:53:24Z

Originally by RolfRabenseifner on 2013-08-23 03:31:19 -0500

Replying to longb:

I assume the first sentence "The known corrections to MPI-3.0 are listed in this document." is intended to apply only to the corrections regarding the Fortran interface and not ALL corrections to MPI-3.0.

This is only the standard framework sentence of the whole errata document as used in http://www.mpi-forum.org/docs/errata-30.pdf

Of course, this #388 contains only a small subset of all known corrections.

Page 6, line 25, "its" should be "their".

Done and uploaded. I did not rename the version of the document because it has still same page and line numbers.

mpiforumbot · 2016-07-24T20:53:25Z

Originally by RolfRabenseifner on 2013-08-23 03:44:25 -0500

Replying to rasmus:

I have a preference for,
my_rename => MPI_Isend_f08ts
over
my_noname => MPI_Isend_f08ts

I kept the name my_noname. Reasons:

For the MPI-document, both names are possible, because the meaning of this
statement is explained in the advice to users.
In the profiling software written based on this advice,
it is better to have "my_noname", because it tells that the
name is unused. The symbol "=>" tells that this is a renaming.

mpiforumbot · 2016-07-24T20:53:25Z

Originally by schulzm on 2013-08-26 15:46:59 -0500

I am looking through ticket #388 and have a few comments:

Page 4 - why the following? Not sure I follow this advice.

Therefore, for wrapper routines that are part of a Fortran application, it may be more convenient to make the name shift within the application, i.e., to substitute the call to the MPI routine (e.g., MPI_ISEND) by a call to a user-written profiling wrapper with a new name (e.g., X_MPI_ISEND) and to call the Fortran MPI_ISEND from this wrapper, instead of using the PMPI

Page 5 - doesn't this eliminate the possibility of optimization, i.e., using the non subarray version if only simple types are used. With this statement, a call always has to create a descriptor, doesn't it?

To set MPI_SUBARRAYS_SUPPORTED to .TRUE. within a Fortran support method, it is required that all non-blocking and split-collective routines with buffer arguments are implemented according to 1B and 2B, i.e., with MPI_Xxxx_f08ts in the mpi_f08 module, and with MPI_XXXX_FTS in the mpi module and the mpif.h include file.

The paragraph spanning page 6 and 7 should really be in or referenced from the profiling section in the tools chapter.

Page 7: the following is not correct:

The profiling routine can internally call the matching PMPI routine with any of its existing bindings, except for routines that have callback routine dummy arguments, choice buffer arguments, or that are attribute caching routines (MPI_{COMM|WIN|TYPE}_{SET|GET}_ATTR). In this case, the profiling software must invoke the corresponding PMPI routine using the same Fortran support method as used in the calling application program, because the C, mpi_f08 and mpi callback prototypes are different or the meaning of the choice buffer or attribute_val arguments are different.

For a choice buffer I don't have to call the corresponding PMPI routine - putting this in the standard would make a large array of tools not standard compliant anymore. It should still be legal to a) take the descriptor apart and send it one by one or b) create a datatype and send it that way or … - we also have tools that do nothing and just drop messages (on purpose). It should read something like if the wrapper just wants to pass on the arguments and wants to call the corresponding routine without changing the arguments, then it has to do so using the same support mechanism.

In general the missing discussion of consequences for tools that don't just wrap 1:1 worries me a bit - I wonder if we are running into any more traps here.

mpiforumbot · 2016-07-24T20:53:26Z

Originally by RolfRabenseifner on 2013-08-27 00:11:15 -0500

Replying to schulzm:

I am looking through ticket #388 and have a few comments:

Page 4 - why the following? Not sure I follow this advice.

"Therefore, for wrapper routines that are part of a Fortran application, it may be more convenient to make the name shift within the application, i.e., to substitute the call to the MPI routine (e.g., MPI_ISEND) by a call to a user-written profiling wrapper with a new name (e.g., X_MPI_ISEND) and to call the Fortran MPI_ISEND from this wrapper, instead of using the PMPI interface." (page 4, lines 38-42)

In this section, advices to users are directed to to different groups:

User = writer of the MPI application.
User = writer of a middleware layer (tool) between the application and the MPI library.

The PMPI was always open to both groups.

The cited text on page 4 is for the first group.
This advice is only for the first group (wording: "for wrapper routines that are part of a

Fortran application").
Because the MPI-3.0 Fortran interface back-end (original Sect. 17.1.5), and also
corrected back-end proposed in this ticket imply that a middleware must intercept
several linker names (original version) or specific procedure names (proposed in
this correction), it may be for this first group sometimes more convenient
to proceed as described in this text.

Page 5 - doesn't this eliminate the possibility of optimization, i.e., using the non subarray version if only simple types are used. With this statement, a call always has to create a descriptor, doesn't it?

"To set MPI_SUBARRAYS_SUPPORTED to .TRUE. within a Fortran support method, it is required that all non-blocking and split-collective routines with buffer arguments are implemented according to 1B and 2B, i.e., with MPI_Xxxx_f08ts in the mpi_f08 module, and with MPI_XXXX_FTS in the mpi module and the mpif.h include file." (page 5, lines 37-40)

Subarrays cannot be supported without using this "TYPE(*), DIMENSION(..)" and the compiler

produces such a descriptor. In the case of a simple type, the descriptor is small.
This is a significant part of MPI-3.0 and the decisions for MPI-3.0 and we do not change this.
In the existing MPI-3.0, this was the need to use the BIND(C) implementations with these descriptors.

The paragraph spanning page 6 and 7 should really be in or referenced from the profiling section in the tools chapter.

This is a capability that was significant part of the existing MPI-3.0 Sect. 17.1.5.
It was a design goal for the new Fortran enhancements in MPI-3.0.
We kept this quality of Sect. 17.1.5 unchanged.
Because MPI-3.0 did not include further comments on this behavior in the tools
chapter on this, we do not added new text to the tools chapter.

It may be a good idea to add in the tools chapter a link to this text in a
follow-up ticket and decide there whether this link would be an erratum
(correcting some missing information in the tools chapter) or new text.

Page 7: the following is not correct:

"The profiling routine can internally call the matching PMPI routine with any of its existing bindings, except for routines that have callback routine dummy arguments, choice buffer arguments, or that are attribute caching routines (MPI_{COMM|WIN|TYPE}_{SET|GET}_ATTR). In this case, the profiling software must invoke the corresponding PMPI routine using the same Fortran support method as used in the calling application program, because the C, mpi_f08 and mpi callback prototypes are different or the meaning of the choice buffer or attribute_val arguments are different." (page 7 lines 1-7)

For a choice buffer I don't have to call the corresponding PMPI routine - putting this in the standard would make a large array of tools not standard compliant anymore. It should still be legal to a) take the descriptor apart and send it one by one or b) create a datatype and send it that way or … - we also have tools that do nothing and just drop messages (on purpose). It should read something like if the wrapper just wants to pass on the arguments and wants to call the corresponding routine without changing the arguments, then it has to do so using the same support mechanism.

In general the missing discussion of consequences for tools that don't just wrap 1:1 worries me a bit - I wonder if we are running into any more traps here.

MPI-3.0 page 606, lines 21-25 originally says:

"The profiling routine can internally call the matching PMPI routine with any of its existing bindings, except for routines that have callback routine dummy arguments. In this case, the profiling software must use the same Fortran support method as used in the calling application program, because the C, mpi_f08 and mpi callback prototypes are different."

We extended this, because the different meaning of the arguments is given for
all three groups of routines:

MPI routines with callback routine arguments
MPI_{COMM|WIN|TYPE}_{SET|GET}_ATTR
MPI routines with choice buffers.

This fact has not changed since MPI-3.0 by this ticket.
It is correct, that there are ways to solve the missing argument match by some
work-arounds, e.g., passing a different datatype.
The sentence is to strict. It wanted to tell, direct Fortran:C mapping is not
possible for these routines.
It does not want to disallow complex mappings, as long as the semantics of the
MPI call is preserved.

I propose the simple correction:

Page 7, lines 4-5 read

In this case, the profiling software must invoke ...

but should read ("should" instead of "must")

In this case, the profiling software should invoke ...

Okay?

mpiforumbot · 2016-07-24T20:53:26Z

Originally by RolfRabenseifner on 2013-08-27 03:38:48 -0500

Attachment added: errata-30-ticket388-2013-08-27.pdf (174.1 KiB)
Errata for the Fortran support methods to solve the "LOGICAL-BIND(C)-problem"

mpiforumbot · 2016-07-24T20:53:27Z

Originally by RolfRabenseifner on 2013-08-27 03:42:57 -0500

The proposed change of "must invoke" to "should invoke" is the only change from pdf version 2013-08-22 to 2013-08-27. In the ticket description, only the link to the pdf was changed.

mpiforumbot · 2016-07-24T20:53:28Z

Originally by jsquyres on 2013-08-27 07:31:24 -0500

I'm ok with Rolf's single change to the 2013-08-27 PDF (compared to the 2013-08-22 PDF). Reviewed ok.

mpiforumbot · 2016-07-24T20:53:28Z

Originally by RolfRabenseifner on 2013-08-27 08:04:26 -0500

After the reviews from Craig (comments 8+12, answer 15), Rolf (comment 9),
Jeff S. (Comment 11+19), Bill L. (comment 13, answer 14), and Martin (comment 16, answer 17+18,19),
I switch the ticket's priority to "Proposal reviewed".

mpiforumbot · 2016-07-24T20:53:29Z

Originally by RolfRabenseifner on 2013-08-27 08:06:03 -0500

The ticket is scheduled for reading and voting on the agenda of the Madrid meeting, Sep. 2013.

mpiforumbot · 2016-07-24T20:53:29Z

Originally by RolfRabenseifner on 2013-09-11 04:40:37 -0500

Attachment added: errata-30-ticket388-2013-09-05.pdf (173.9 KiB)
Errata for the Fortran support methods to solve the "LOGICAL-BIND(C)-problem" plus ticket-0-corrections from reviews

mpiforumbot · 2016-07-24T20:53:30Z

Originally by RolfRabenseifner on 2013-09-11 05:25:53 -0500

During the review period (2 weeks before the meeting in Madrid, Sep. 2013), we
received two reviews by email.

One without further requests for change ("We are prepared to support this proposal"), and
one with the hint that it would be better to move the advice in the pdf
from Aug. 27, 2013, page 4 lines 29-43 to the end of the section,
i.e., after page 9 line 24.
This proposal is also supported by the chapter committee,
see new pdf from Sep. 5, 2013, page 9, lines 11-25.
To include it into the context at the end of the section, we added the words
"as shown in the example code above", see line 20.

I propose to treat this text-move as an editorial ticket-0 change and to proceed with the
reading at the MPI forum meeting in Madrid with this new version from Sep. 4, 2013.
I'll add the new pdf to the solution-section of this ticket.

mpiforumbot · 2016-07-24T20:53:31Z

Originally by RolfRabenseifner on 2013-09-11 05:32:35 -0500

Added to the solution section:

Based on the reviews, ticket-0-editorial changes were added before the reading of the ticket,
see attached pdf file:[[BR]]
attachment:errata-30-ticket388-2013-09-05.pdf
[[BR]]This version is proposed for the reading in Madrid.

mpiforumbot · 2016-07-24T20:53:31Z

Originally by RolfRabenseifner on 2013-09-12 10:46:34 -0500

Attachment added: errata-30-ticket388-2013-09-12.pdf (173.5 KiB)
Errata for the Fortran support methods to solve the "LOGICAL-BIND(C)-problem" plus ticket-0-corrections from reviews + formal reading

mpiforumbot · 2016-07-24T20:53:31Z

Originally by RolfRabenseifner on 2013-09-12 10:48:05 -0500

I added the ticket-0 changes from the formal reading at Madrid.

mpiforumbot · 2016-07-24T20:53:34Z

Originally by jsquyres on 2014-05-15 09:06:15 -0500

I sent around a PDF and diffs to be reviewed: http://lists.mpi-forum.org/mpiwg-fortran/2014/05/1495.php

Once they're reviewed, I'll commit the text to SVN.

mpiforumbot · 2016-07-24T20:53:37Z

Originally by RolfRabenseifner on 2015-02-04 11:08:59 -0600

One small bugs, therefore ticket reopened and put back one stage:

The correction on MPI-3.0 page 411 line 27 "specific procedure names" is not done.

mpiforumbot · 2016-07-24T20:53:39Z

Originally by jsquyres on 2015-02-04 11:27:34 -0600

Rolf --

I actually find 3 places where this text is very similar, but not exactly the same:

MPI_ALLOC_MEM_CPTR

Index: MPI-3.1/chap-inquiry/inquiry.tex
===================================================================
--- MPI-3.1/chap-inquiry/inquiry.tex    (revision 1840)
+++ MPI-3.1/chap-inquiry/inquiry.tex    (revision 1841)
@@ -307,7 +307,7 @@
 END INTERFACE
 \end{verbatim}

-The linker name base of this overloaded function is \mpifunc{MPI\_ALLOC\_MEM\_CPTR}. The implied linker names
+The base procedure name of this overloaded function is \mpifunc{MPI\_ALLOC\_MEM\_CPTR}. The implied specific procedure names
 are described in \sectionref{sec:f90:linker-names}.

 The \mpiarg{info} argument can be used to provide

MPI_WIN_ALLOCATE_CPTR

Index: MPI-3.1/chap-one-side/one-side-2.tex
===================================================================
--- MPI-3.1/chap-one-side/one-side-2.tex    (revision 1842)
+++ MPI-3.1/chap-one-side/one-side-2.tex    (revision 1843)
@@ -351,7 +351,7 @@
 \end{verbatim}


-The linker name base of this overloaded function is \mpifunc{MPI\_WIN\_ALLOCATE\_CPTR}. The implied linker names
+The base procedure name of this overloaded function is \mpifunc{MPI\_WIN\_ALLOCATE\_CPTR}. The specific procedure names
 are described in \sectionref{sec:f90:linker-names}.

 \begin{rationale}

MPI_WIND_SHARED_QUERY_CPTR

Index: MPI-3.1/chap-one-side/one-side-2.tex
===================================================================
--- MPI-3.1/chap-one-side/one-side-2.tex    (revision 1846)
+++ MPI-3.1/chap-one-side/one-side-2.tex    (revision 1847)
@@ -548,7 +548,7 @@
 END INTERFACE
 \end{verbatim}

-The linker name base of this overloaded function is \mpifunc{MPI\_WIN\_SHARED\_QUERY\_CPTR}. The implied linker names
+The base procedure name of this overloaded function is \mpifunc{MPI\_WIN\_SHARED\_QUERY\_CPTR}. The implied linker names
 are described in \sectionref{sec:f90:linker-names}.

 \subsection{Window of Dynamically Attached Memory}

I think 2 is the most correct -- 1 and 3 should be adjusted the match 2.

What do you think?

mpiforumbot · 2016-07-24T20:53:39Z

Originally by RolfRabenseifner on 2015-02-05 02:33:46 -0600

According to the ticket, it is three times version one:

The implied specific procedure names

mpiforumbot · 2016-07-24T20:53:40Z

Originally by jsquyres on 2015-02-05 06:14:04 -0600

Attachment added: mpi31-report-ticket-388-r1933.pdf (2603.5 KiB)
SVN r1933

mpiforumbot · 2016-07-24T20:53:40Z

Originally by jsquyres on 2015-02-05 06:15:50 -0600

Done. New PDF attached to the ticket; the fixes are on pages 406:34 and 410:13.

mpiforumbot self-assigned this Jul 24, 2016

mpiforumbot added Correction to standard (for upcoming release + errata) Ticket complete MPI 3.0 errata Text committed labels Jul 24, 2016

mpiforumbot removed the Ticket complete label Jul 24, 2016

mpiforumbot added the Scheduled label Jul 24, 2016

mpiforumbot added Passed and removed Scheduled labels Jul 24, 2016

mpiforumbot added Waiting for PDF reviews Ticket complete and removed Passed Waiting for PDF reviews labels Jul 24, 2016

mpiforumbot closed this as completed Jul 24, 2016

mpiforumbot added Waiting for PDF reviews and removed Ticket complete labels Jul 24, 2016

mpiforumbot reopened this Jul 24, 2016

mpiforumbot added Ticket complete and removed Waiting for PDF reviews labels Jul 24, 2016

mpiforumbot closed this as completed Jul 24, 2016

This was referenced Jul 24, 2016

MPI-3.0 errata: Correcting Fortran _CPTR interface descriptions #390

Closed

Fortran module CONTAINS - Advice to implementors #393

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem #388

MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem #388

mpiforumbot commented Jul 24, 2016 •

edited

Loading

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem #388

MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem #388

Comments

mpiforumbot commented Jul 24, 2016 • edited Loading

Description

Extended Scope

History

Proposed Solution (as MPI-3.0 errata)

Description

Extended Scope

History

Proposed Solution (as MPI-3.0 errata)

Impact on Implementations

Impact on Applications / Users

Alternative Solutions

Entry for the Change Log

Voting category

Impact on Implementations

Impact on Applications / Users

Alternative Solutions

Entry for the Change Log

Voting category

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016

mpiforumbot commented Jul 24, 2016 •

edited

Loading