search

mpi-forum / mpi-forum-historic

Migration of old MPI Forum Trac Tickets to GitHub. New issues belong on mpi-forum/mpi-issues.
http://www.mpi-forum.org
2 stars 3 forks source link

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

Closed mpiforumbot closed 8 years ago

mpiforumbot commented 8 years ago

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:

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 commented 8 years ago

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

Link to pdf file added to the Solution section.

mpiforumbot commented 8 years ago

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

First Change-log item updated.

mpiforumbot commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

Typo corrections in the attached pdf file.

mpiforumbot commented 8 years ago

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

Typo corrections

mpiforumbot commented 8 years ago

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 commented 8 years ago

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

To follow-up Craig's review:

The proposed solution is

mpiforumbot commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

mpiforumbot commented 8 years ago

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 commented 8 years ago

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:

mpiforumbot commented 8 years ago

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 commented 8 years ago

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:

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:

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

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

mpiforumbot commented 8 years ago

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 commented 8 years ago

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

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

mpiforumbot commented 8 years ago

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:

  1. 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
  1. 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}
  1. 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.