May 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] [MPI Forum] #424: Incorrect Fortran type for flag in IMPROBE
by Junchao Zhang 16 May '14

16 May '14

I just checked. For F77, F90 and F08, we all used LOGICAL for the flag argument. That is great! --Junchao Zhang On Fri, May 16, 2014 at 1:40 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com > wrote: > On May 16, 2014, at 2:25 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > have you be aware of this #424? > > I am now. :-) > > > Had OpenMPI detected this inconsistency and done it "right"? > > Yes, we used LOGICAL, not INTEGER. I didn't even notice that it was > *supposed* to be INTEGER. > > Bill/Junchao -- did you use INTEGER or LOGICAL? If you used LOGICAL, too, > then we can probably make this an errata and not worry about backwards > compatibility issues. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > >

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

On May 16, 2014, at 12:17 PM, Bill Long <longb(a)cray.com> wrote: >> The term "not interceptable" conveys the important restriction. How > > I agree this is the important concept. Somehow the compiler, through optimization, macros, automatic inlining,…, creates an object file that does not contain the That may all be true, but I think it is a different thing, and is not what I am proposing. To be clear: WTICK/WTIME were explicitly allowed to be macros *in C* ever since MPI-2.0. I am not changing that in my proposal (now ticket #428). #428 only fixes MPI_SIZEOF and the status-conversion functions. Someone else is free to propose the ability of WTICK/WTIME to be inlined in Fortran, but that requires a little more spelunking in history to know why that was done in MPI-2... which I do not have time for at the moment. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] [MPI Forum] #424: Incorrect Fortran type for flag in IMPROBE
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

On May 16, 2014, at 2:25 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > have you be aware of this #424? I am now. :-) > Had OpenMPI detected this inconsistency and done it "right"? Yes, we used LOGICAL, not INTEGER. I didn't even notice that it was *supposed* to be INTEGER. Bill/Junchao -- did you use INTEGER or LOGICAL? If you used LOGICAL, too, then we can probably make this an errata and not worry about backwards compatibility issues. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Fwd: [MPI Forum] #424: Incorrect Fortran type for flag in IMPROBE
by Rolf Rabenseifner 16 May '14

16 May '14

Jeff, have you be aware of this #424? Had OpenMPI detected this inconsistency and done it "right"? I would say that the Fortran WG should do this errata until Monday. Best regards Rolf ----- Forwarded Message ----- From: "MPI Forum" <mpi-forum(a)lists.mpi-forum.org> Sent: Friday, May 16, 2014 8:21:55 PM Subject: Re: [MPI Forum] #424: Incorrect Fortran type for flag in IMPROBE #424: Incorrect Fortran type for flag in IMPROBE -------------------------------------+------------------------------------- Reporter: gropp | Owner: Type: Correction to standard | Status: new (for upcoming release + errata) | Milestone: 2014/06/02 Priority: Not ready / author | Chicago, USA rework | Resolution: Version: MPI 3.0 errata | Implementation status: Unnecessary Keywords: | -------------------------------------+------------------------------------- Changes (by RolfRabenseifner): * cc: jsquyres@…, rabenseifner@… (added) Comment: It is a real bug and inconsistency because p68:12 clearly states "logical". Therefore it should be corrected by an erratum which solves the problem from the beginning. '''Solution:''' MPI-3.0 p68:22 reads INTEGER, INTENT(OUT) {{{::}}} flag but should read LOGICAL, INTENT(OUT) {{{::}}} flag and p68:28-29 read INTEGER SOURCE, TAG, COMM, FLAG, MESSAGE, STATUS(MPI_STATUS_SIZE),[[BR]] IERROR but should read INTEGER SOURCE, TAG, COMM, MESSAGE, STATUS(MPI_STATUS_SIZE), IERROR [[BR]] LOGICAL FLAG -- Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/424#comment:1> MPI Forum <https://svn.mpi-forum.org/> MPI Forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Bill Long 16 May '14

16 May '14

On May 16, 2014, at 11:04 AM, N.M. Maclaren <nmm1(a)cam.ac.uk> wrote: > On May 16 2014, Jeff Squyres (jsquyres) wrote: >> On May 16, 2014, at 11:14 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >>> We need a correct expression telling that it is allowed to be not interceptable. >>> MPI-3.0 wording: "as macro in C." >>> [does not tell anything about Fortran] >> >> Per my other mail, I think we don't want to touch this in an errata. Allowing WTICK/WTIME to be inlined in Fortran -- which I intentionally avoided in the original proposal -- is a new thing, and should wait until MPI-4. >> >> My proposal was amended by your prior mail, but I do not like this "Maybe better proposal" you sent. >> >> To be clear, here's what I'm currently proposing: >> >> ----- An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, and the handle- ***and status-*** conversion functions (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, and no others, as macros in C ***or inlined in Fortran***. ***MPI_SIZEOF may also be inlined.*** > > I agree with Rolf's wording. Talking about inlining in C is a mistake, > too - but MPI didn't start it - WG14 did. But it is a REALLY bad idea > in Fortran, which (generally) doesn't talk about implementation at all. > It didn't even assume floating-point reals until Fortran 90! > > The term "not interceptable" conveys the important restriction. How I agree this is the important concept. Somehow the compiler, through optimization, macros, automatic inlining,…, creates an object file that does not contain the expected external symbol that can be satisfied by a substitute (interceptor) routine. This general concept is independent of language (C or Fortran). The intent of the text is that there is a set of MPI_* routines that are allowed in this class, the spec lists the maximal set, and the implementation is obligated to document its actual set. Cheers, Bill > an implementation handles MPI_Sizeof is up to it - as I said, using a > preprocessor is one possibility, and has been and is done for other > purposes. > > > Regards, > Nick Maclaren. > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by N.M. Maclaren 16 May '14

16 May '14

On May 16 2014, Jeff Squyres (jsquyres) wrote: > On May 16, 2014, at 11:14 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > >> We need a correct expression telling that it is allowed to be >> not interceptable. >> >> MPI-3.0 wording: "as macro in C." >> [does not tell anything about Fortran] > > Per my other mail, I think we don't want to touch this in an errata. > Allowing WTICK/WTIME to be inlined in Fortran -- which I intentionally > avoided in the original proposal -- is a new thing, and should wait until > MPI-4. > > My proposal was amended by your prior mail, but I do not like this "Maybe > better proposal" you sent. > >To be clear, here's what I'm currently proposing: > > ----- An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > PMPI_WTIME, PMPI_WTICK, and the handle- ***and status-*** conversion > functions (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and > 17.2.5***, and no others, as macros in C ***or inlined in Fortran***. > ***MPI_SIZEOF may also be inlined.*** I agree with Rolf's wording. Talking about inlining in C is a mistake, too - but MPI didn't start it - WG14 did. But it is a REALLY bad idea in Fortran, which (generally) doesn't talk about implementation at all. It didn't even assume floating-point reals until Fortran 90! The term "not interceptable" conveys the important restriction. How an implementation handles MPI_Sizeof is up to it - as I said, using a preprocessor is one possibility, and has been and is done for other purposes. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

On May 16, 2014, at 11:24 AM, Jeff Squyres <jsquyres(a)cisco.com> wrote: > To be clear, here's what I'm currently proposing: GAH! I copied-pasted too much; the last one I sent was incorrect. Sorry for the confusion! There is sufficient interest in this such that I made a ticket and put the definitive version there: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428 We can keep discussing here in this thread, but at least the definitive text is now on the ticket. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

On May 16, 2014, at 11:14 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > We need a correct expression telling that it is allowed to be > not interceptable. > > MPI-3.0 wording: "as macro in C." > [does not tell anything about Fortran] Per my other mail, I think we don't want to touch this in an errata. Allowing WTICK/WTIME to be inlined in Fortran -- which I intentionally avoided in the original proposal -- is a new thing, and should wait until MPI-4. My proposal was amended by your prior mail, but I do not like this "Maybe better proposal" you sent. To be clear, here's what I'm currently proposing: ----- An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, and the handle- ***and status-*** conversion functions (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, and no others, as macros in C ***or inlined in Fortran***. ***MPI_SIZEOF may also be inlined.*** Advice to implementors. Implementors should document which routines are implemented as macros ***or otherwise inlined***. (End of advice to implementors.) Advice to users. If these routines are implemented as macros ***or otherwise inlined***, they will not work with the MPI profiling interface. (End of advice to users.) ----- and ----- 1. provide a mechanism through which all of the MPI defined functions, except those allowed as macros ***or otherwise inlined*** (See Section 2.6.4), may be accessed with a name shift. This requires, in C and Fortran, an alternate entry point name, with the prefix PMPI_ for each MPI function in each provided language binding and language support method. For routines implemented as macros ***or otherwise inlined***, it is still required that the PMPI_ version be supplied and work as expected, but it is not possible to replace at link time the MPI_ version with a user-defined version. ------ -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

I agree with everything (good catch on the status conversion routines), but I think the "***or inlined in Fortran***" phrase is a separate/new thing. Fortran was specifically not mentioned in the original text (w.r.t. WTICK and WTIME); if we want to change that, I think that's a separate/new thing. It could have ABI issues, for example, and would therefore have to go to MPI-4. I think the rest of this can go in as errata. On May 16, 2014, at 9:59 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Samll updates, see below. > > I corrected the page number and I added > - "or inlined in Fortran", and > - the status-conversion routines in 17.2.5 > (They were new in MPI-3.0 and we oversaw that they > have similar quality as handle-conversion routines. > Major difference, they have an out-argument > within the argument list.) > > Do we also consensus in adding the status-conversions > to the macro+inline-allowence? > Or do we need to spilt these two things? > > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org>, "MPI Tool WG" <mpiwg-tools(a)lists.mpi-forum.org> >> Sent: Friday, May 16, 2014 2:44:10 PM >> Subject: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled >> >> Fortran and Tools WGs: >> >> (=== this is a bit urgent if we want to get this read at the Chicago >> meeting; the T-2 deadline is this upcoming Monday morning ===) >> >> We seem to have some measure of consensus on the other thread that >> MPI_SIZEOF should not be profiled. >> >> Note, however, that the Tools chapter currently mandates that PMPI_ >> versions of all MPI routines must be available (including, for >> example, MPI_WTICK), but the MPI_ versions do not have to be >> replaceable at link time. I propose adopting this convention for >> MPI_SIZEOF, too (i.e. we have to provide PMPI_SIZEOF). >> >> Does this wording work as a proposal? >> > MPI-3.0 p19:45 through p20:5 (T&C chapter) currently reads: > (Jeff, you may used a wrong pdf with ther page numbers) >> >> ----- >> An implementation is allowed to implement MPI_WTIME, MPI_WTICK, >> PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions >> (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in >> C. >> >> Advice to implementors. Implementors should document which routines >> are implemented as macros. (End of advice to implementors.) >> >> Advice to users. If these routines are implemented as macros, they >> will not work with the MPI profiling interface. (End of advice to >> users.) >> ----- >> >> but should read (new text in ***): >> >> ----- >> An implementation is allowed to implement MPI_WTIME, MPI_WTICK, >> PMPI_WTIME, PMPI_WTICK, and the handle- > ***and status-*** >> conversion functions >> (MPI_Group_f2c, etc.) in Section***s*** 17.2.4 ***and 17.2.5***, >> and no others, as macros in C > ***or inlined in Fortran***. >> ***MPI_SIZEOF may also be inlined.*** >> >> Advice to implementors. Implementors should document which routines >> are implemented as macros ***or otherwise inlined***. (End of advice >> to implementors.) >> >> Advice to users. If these routines are implemented as macros ***or >> otherwise inlined***, they will not work with the MPI profiling >> interface. (End of advice to users.) >> ----- >> >> p555:31-37 (first page of the Tools chapter) currently says: >> >> ----- >> 1. provide a mechanism through which all of the MPI defined >> functions, except those allowed as macros (See Section 2.6.4), may >> be accessed with a name shift. This requires, in C and Fortran, an >> alternate entry point name, with the prefix PMPI_ for each MPI >> function in each provided language binding and language support >> method. For routines implemented as macros, it is still required >> that the PMPI_ version be supplied and work as expected, but it is >> not possible to replace at link time the MPI_ version with a >> user-defined version. >> ----- >> >> but should say >> >> ----- >> 1. provide a mechanism through which all of the MPI defined >> functions, except those allowed as macros ***or otherwise inlined*** >> (See Section 2.6.4), may be accessed with a name shift. This >> requires, in C and Fortran, an alternate entry point name, with the >> prefix PMPI_ for each MPI function in each provided language binding >> and language support method. For routines implemented as macros >> ***or otherwise inlined***, it is still required that the PMPI_ >> version be supplied and work as expected, but it is not possible to >> replace at link time the MPI_ version with a user-defined version. >> ----- >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Jeff Squyres (jsquyres) 16 May '14

16 May '14

On May 16, 2014, at 10:09 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > "any routine with a name starting with MPI_ or PMPI_ has to come from the mpi libraries and cannot be supplied by the user?" > > This is in the standard. The MPI namespace is reserved. Apps that use it are in violation. ...except when you're profiling and intercepting/overriding MPI_* functions. :-) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0