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

Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Bill Long 19 May '14

19 May '14

On May 19, 2014, at 5:27 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > About https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428 > >> It is far better to say what you mean, that say something which most >> people believe is equivalent, because it won't be for all compilers >> or necessarily so in the future. > > Yes, therefore I would like to see a wording like > > 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 Sections 17.2.4 and 17.2.5, and no others, as macros in C. > ***MPI_SIZEOF and PMPI_SIZEOF may also be implemented > such that they may not be interceptable.*** > > Advice to implementors. Implementors should document > which routines are implemented as macros ***or otherwise > non-interceptable***. (End of advice to implementors.) > > Advice to users. If these routines are implemented > as macros ***or otherwise non-interceptable***, they will not > work with the MPI profiling interface. (End of advice to users.) > > > But for an Erratum, it should be a minimal change. > Currently, C applications can test wether a MPI_Wtime macro is defined. > There is no need to change this. > > For Fortran, I learnt from these mails, that we Need to scpecify the > outcome: non-intereptable. I’m still concerned about making a distinction between Fortran and C that is entirely artificial. If a Fortran program wants to avoid interception of MPI_WTICK, for example, it is trivial to write a wrapper C function my_wtick_ that contains the macro for MPI_Wtick. Macros in C are just another form of inlining. I think it would be better to merge together text from Martin and Rolf to end up with something simpler and clearer: An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the handle- and status-conversion functions (MPI_Group_f2c, etc.) in Sections 17.2.4 and 17.2.5, and no others, such that they are not interceptable. Advice to implementors. Implementors should document which routines are implemented such that they are not interceptable. (End of advice to implementors.) Advice to users. If these routines are implemented as not interceptable, they will not work with the MPI profiling interface. (End of advice to users.) > > Best regards > Rolf > > ----- Original Message ----- >> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Cc: mpiwg-tools(a)lists.mpi-forum.org >> Sent: Sunday, May 18, 2014 12:02:32 PM >> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled >> >> On May 18 2014, Martin Schulz wrote: >>> >>> I agree with what you are planning to propose, I am not sure, >>> though, the >>> wording is quite right, and with this I mean more the wording in the >>> existing standard: this sound like as if all these functions are >>> still >>> interceptable in Fortran. >>> >>> What if we say: >>> >>> An implementation is allowed to implement MPI_WTIME, MPI_WTICK, >>> PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the >>> handle-conversion >>> functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as >>> macros in C or allow them to be inlined. >>> >>> Advice to implementors. Implementors should document which routines >>> are >>> implemented as macros or are implemented so that they can be >>> inlined. (End >>> of advice to implementors.) >>> >>> Advice to users. If these routines are implemented as macros or are >>> inlined, they will not work with the MPI profiling interface. (End >>> of >>> advice to users.) >> >> Basically, what you are doing is spelling out what the term 'inline' >> means in MPI, but it is STILL technically wrong and remains >> confusing. >> Lots of compilers generate multiple calling sequences with different >> properties - that is near-universal for library calls, but isn't rare >> for highly optimised user ones. Well, those are not inlined, and not >> interceptable. >> >> That is also true in C and C++, incidentally, where the word 'inline' >> means two subtly different things, neither of which is particularly >> close to the concept on 'inlining' being debated in this thread. But >> that mess originated in C99, where 'inline' had a LOT of opposition >> on >> precisely these grounds. >> >> It is far better to say what you mean, that say something which most >> people believe is equivalent, because it won't be for all compilers >> or >> necessarily so in the future. >> >> >> Regards, >> Nick Maclaren. >> >> >> _______________________________________________ >> 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 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

Fwd: [MPI Forum] #403: Error in description of size-specific types
by Rolf Rabenseifner 19 May '14

19 May '14

Dear Fortran WG, Bill Gropp has detected a bug in the Fortran Interface text on MPI-3.0 page 620 and proposed a perfect correction. I would like to set this to "scheduled" as MPI-3.0 Erratum at the upcoming Forum meeting. Okay? Best regards Rolf ----- Forwarded Message ----- From: "MPI Forum" <mpi-forum(a)lists.mpi-forum.org> Sent: Monday, May 19, 2014 12:49:22 PM Subject: Re: [MPI Forum] #403: Error in description of size-specific types #403: Error in description of size-specific types -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Comment (by RolfRabenseifner): Review: For me, the solution seems to be perfect. -- Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/403#comment:4> 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] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 19 May '14

19 May '14

About https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/428 > It is far better to say what you mean, that say something which most > people believe is equivalent, because it won't be for all compilers > or necessarily so in the future. Yes, therefore I would like to see a wording like 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 Sections 17.2.4 and 17.2.5, and no others, as macros in C. ***MPI_SIZEOF and PMPI_SIZEOF may also be implemented such that they may not be interceptable.*** Advice to implementors. Implementors should document which routines are implemented as macros ***or otherwise non-interceptable***. (End of advice to implementors.) Advice to users. If these routines are implemented as macros ***or otherwise non-interceptable***, they will not work with the MPI profiling interface. (End of advice to users.) But for an Erratum, it should be a minimal change. Currently, C applications can test wether a MPI_Wtime macro is defined. There is no need to change this. For Fortran, I learnt from these mails, that we Need to scpecify the outcome: non-intereptable. Best regards Rolf ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: mpiwg-tools(a)lists.mpi-forum.org > Sent: Sunday, May 18, 2014 12:02:32 PM > Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled > > On May 18 2014, Martin Schulz wrote: > > > >I agree with what you are planning to propose, I am not sure, > >though, the > >wording is quite right, and with this I mean more the wording in the > >existing standard: this sound like as if all these functions are > >still > >interceptable in Fortran. > > > >What if we say: > > > >An implementation is allowed to implement MPI_WTIME, MPI_WTICK, > >PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the > >handle-conversion > >functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as > >macros in C or allow them to be inlined. > > > >Advice to implementors. Implementors should document which routines > >are > >implemented as macros or are implemented so that they can be > >inlined. (End > >of advice to implementors.) > > > >Advice to users. If these routines are implemented as macros or are > >inlined, they will not work with the MPI profiling interface. (End > >of > >advice to users.) > > Basically, what you are doing is spelling out what the term 'inline' > means in MPI, but it is STILL technically wrong and remains > confusing. > Lots of compilers generate multiple calling sequences with different > properties - that is near-universal for library calls, but isn't rare > for highly optimised user ones. Well, those are not inlined, and not > interceptable. > > That is also true in C and C++, incidentally, where the word 'inline' > means two subtly different things, neither of which is particularly > close to the concept on 'inlining' being debated in this thread. But > that mess originated in C99, where 'inline' had a LOT of opposition > on > precisely these grounds. > > It is far better to say what you mean, that say something which most > people believe is equivalent, because it won't be for all compilers > or > necessarily so in the future. > > > Regards, > Nick Maclaren. > > > _______________________________________________ > 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)

1 0

Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by N.M. Maclaren 18 May '14

18 May '14

On May 18 2014, Martin Schulz wrote: > >I agree with what you are planning to propose, I am not sure, though, the >wording is quite right, and with this I mean more the wording in the >existing standard: this sound like as if all these functions are still >interceptable in Fortran. > >What if we say: > >An implementation is allowed to implement MPI_WTIME, MPI_WTICK, >PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the handle-conversion >functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as >macros in C or allow them to be inlined. > >Advice to implementors. Implementors should document which routines are >implemented as macros or are implemented so that they can be inlined. (End >of advice to implementors.) > >Advice to users. If these routines are implemented as macros or are >inlined, they will not work with the MPI profiling interface. (End of >advice to users.) Basically, what you are doing is spelling out what the term 'inline' means in MPI, but it is STILL technically wrong and remains confusing. Lots of compilers generate multiple calling sequences with different properties - that is near-universal for library calls, but isn't rare for highly optimised user ones. Well, those are not inlined, and not interceptable. That is also true in C and C++, incidentally, where the word 'inline' means two subtly different things, neither of which is particularly close to the concept on 'inlining' being debated in this thread. But that mess originated in C99, where 'inline' had a LOT of opposition on precisely these grounds. It is far better to say what you mean, that say something which most people believe is equivalent, because it won't be for all compilers or necessarily so in the future. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
by Martin Schulz 17 May '14

17 May '14

Hi Jeff, I agree with what you are planning to propose, I am not sure, though, the wording is quite right, and with this I mean more the wording in the existing standard: this sound like as if all these functions are still interceptable in Fortran. What if we say: An implementation is allowed to implement MPI_WTIME, MPI_WTICK, PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the handle-conversion functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C or allow them to be inlined. Advice to implementors. Implementors should document which routines are implemented as macros or are implemented so that they can be inlined. (End of advice to implementors.) Advice to users. If these routines are implemented as macros or are inlined, they will not work with the MPI profiling interface. (End of advice to users.) Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/16/14, 5:44 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >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 p20:46 through p21:5 (T&C chapter) currently reads: > >----- >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-conversion functions >(MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C. >***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-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

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

16 May '14

I updated ticket #424. It was reported by Bill Gropp but he did not claimed for being owner. Therefore I updated it as member of the Fortran WG. I had already asked Martin, to put it on the agenda. Jeff, can you proceed with the formal process (announcing, reading, voting)? Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, "Junchao Zhang" <jczhang(a)mcs.anl.gov>, "Bill > Long" <longb(a)cray.com> > Sent: Friday, May 16, 2014 9:40:51 PM > Subject: Re: [MPI Forum] #424: Incorrect Fortran type for flag in IMPROBE > > On May 16, 2014, at 3:08 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > Even if somebody used INTEGER, we need not to worry, because then, > > the routine was unusable, because in Fortran there is no integer > > value > > defined for true and false. > > > > Therefore, this routine was unusable. > > Good point. Let's move this forward as errata. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > -- 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 Jeff Squyres (jsquyres) 16 May '14

16 May '14

Thanks Bill. On May 16, 2014, at 3:47 PM, Bill Long <longb(a)cray.com> wrote: > Rolf added a comment to the ticket about the term “inline”. If it would be helpful, here is a response that hopefully would calm fears in others of this word. > > > "Use of "inline" should be fine here. As Rolf points out, this is not a > defined term in Fortran. Therefore, the meaning is just the ordinary > one: The compilation process "inlines" a Call to routine X by > replacing the setup and branch to the external X with equivalent code > generated IN the current LINE of execution on the would-be caller. If > the computation in X can be performed at compile time, the replacement > code could be very simple. It is also possible that the replacement > code is a call to a different routine that has the same effect as a > call to X. How the compiler accomplishes inlining is outside the > scope of both Fortran and MPI. It is sufficient to know that existing > compilation systems are capable of this process, and that it can lead > to better execution performance. The important fact for the discussion > in this ticket is that the process removes the call to X, thus it is > not possible to intercept a call to X at this point in the code.” > > > Cheers, > Bill > > > > On May 16, 2014, at 11:01 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> 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/ >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 Bill Long 16 May '14

16 May '14

Rolf added a comment to the ticket about the term “inline”. If it would be helpful, here is a response that hopefully would calm fears in others of this word. "Use of "inline" should be fine here. As Rolf points out, this is not a defined term in Fortran. Therefore, the meaning is just the ordinary one: The compilation process "inlines" a Call to routine X by replacing the setup and branch to the external X with equivalent code generated IN the current LINE of execution on the would-be caller. If the computation in X can be performed at compile time, the replacement code could be very simple. It is also possible that the replacement code is a call to a different routine that has the same effect as a call to X. How the compiler accomplishes inlining is outside the scope of both Fortran and MPI. It is sufficient to know that existing compilation systems are capable of this process, and that it can lead to better execution performance. The important fact for the discussion in this ticket is that the process removes the call to X, thus it is not possible to intercept a call to X at this point in the code.” Cheers, Bill On May 16, 2014, at 11:01 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > 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/ > > _______________________________________________ > 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] [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 3:08 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Even if somebody used INTEGER, we need not to worry, because then, > the routine was unusable, because in Fortran there is no integer value > defined for true and false. > > Therefore, this routine was unusable. Good point. Let's move this forward as errata. -- 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 Rolf Rabenseifner 16 May '14

16 May '14

> 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. Even if somebody used INTEGER, we need not to worry, because then, the routine was unusable, because in Fortran there is no integer value defined for true and false. Therefore, this routine was unusable. And, an errata should not have a backward compatibility problem, because it changes the routine from its beginning ;-) Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, "Junchao Zhang" <jczhang(a)mcs.anl.gov>, "Bill > Long" <longb(a)cray.com> > Sent: Friday, May 16, 2014 8:40:55 PM > Subject: Re: [MPI Forum] #424: Incorrect Fortran type for flag in IMPROBE > > 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/ > > -- 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