June 2011 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] MPI function symbol naming convention for tools
by Lionel, Steve 30 Jun '11

30 Jun '11

A minor correction to Rolf's message (and it was a pleasure to meet Rolf in Garching): > Name explanation: > "f08" is an abbrevation for "Fortran interface that requires > at least F2008+TR29113 for its full implementation". > "f08" does not mean that it is for F2008 compilers. Actually, the "f08" MPI module depends on F2003 plus TR29113. It does not depend on any F2008 features not in F2003. However, the TR is written as a modification of F2008, so using "f08" as an abbreviation is reasonable (even though I don't care for it personally). I expect to see compilers that support the TR before they support all of F2008 (or even all of F2003!) Steve Lionel Developer Products Division Software and Services Group Intel Corporation Merrimack, NH

1 0

Re: [MPI3 Fortran] MPI function symbol naming convention for tools
by Rolf Rabenseifner 30 Jun '11

30 Jun '11

After my email-free vacation weeks in Rome and Rimini, I used my travel to the Fortran standardization meeting [they extended the ASYNCHRONOUS attribute to asynchronous (MPI) communication] to read through the total track. As I oversee, the answers are really non-trivial and at the end, they are related to decisions about the implementation of callback routines: First a pre-comment: The mpi module _nostatus does not exist, because in the mpi module, the MPI_STATUS_IGNORE is used. ..._nostatus is only needed in mpi_f08. Constraints: C1. Do not break ABI backward compatibility. (Hubert is asolutely right!) C2. Do not break PMPI. (Thanks to the tools people who pointed this out) C3. Each interface has different linker names. These linker names are well defined and must be used if a user wants to substitute an MPI routine by a user-written wrapper: - MPI_Recv for the C interface - MPI::Recv for the C++ interface - mpi_recv_ (or whatever the Fortran compiler has chosen) for Fortran mpif.h or mpi module (To understand C2 or C3, one should be familiar with MPI-2.2, Chapter 14 "Profiling Interface".) Name explanation: "f08" is an abbrevation for "Fortran interface that requires at least F2008+TR29113 for its full implementation". "f08" does not mean that it is for F2008 compilers. Therefore, it is not planned to have some "f13" in the future. Since MPI-1, we only added a new C++ interface. The new f08 interfdace is an answer to all the unsolved problems introduced in mpif.h that is originally based on a slightly extented Fortran 77. Implications (e.g. for MPI_Recv): I1. The binary routine names for mpi module and mpif.h are and will stay the name that is the linker name that is chosen by the Fortran compiler for MPI_Recv, e.g. mpi_recv_ or mpi_recv__ I2. This routine can be substituted by a user-written Fortran wrapper named MPI_RECV, which is then mapped by the same Fortran compiler to the same name mpi_recv_ or mpi_recv__ I3. It is not allowed to make MPI_Recv a CONTAINS routine of the mpi module because this would be mapped to another linker name. I4. For the new mpi_f08 module we need to define new names for the case that the user wants to substitute such a routine by a wrapper. This is necessary because MPI_Recv in the mpi_f08 module is mapped by the Fortran compiler to the same name as MPI_Recv in mpif.h or the mpi module. And by the same reason as in I3, this routine must not be part of the mpi_f08 module name space. And now, we have the freedom to choose the names for - MPI_Recv in mpi_f08 with the status argument - MPI_Recv in mpi_f08 without the status argument First, we should decide about the postfixes etc. Second, we should decide about the language namespace. First: - MPI_Recv_f08 and MPI_Recv_f08_nostatus (These names should be clear in the sense of readable for human beeings using a debugger. Therefore, it is a bad idea to substitute the module abbreviation by something else, e.g. "desc".) Other name pairs are: - ..._f08 / ..._f08_noweights - ..._f08 / ..._f08_nosourceweights / ..._f08_nodestweights / ..._f08_noweights - ..._f08 / ..._f08_errcodes Second - The user should be able to write a wrapper or to reuse and existing wrapper for the mpi module. Implications: The wrapper should be writable in Fortran. There are two alternatives: A1. mpi_f08 is defined as bind-Fortran routines. An existing application that has an MPI_Recv wrapper which internally calls PMPI_Recv in the mpi module can be substituted by the following changes: - Application routines that call MPI_Recv are modifired to use mpi_f08 - The wrapper routine is duplicated into two new named routines -- MPI_Recv_f08 with status argument and "same" content as existing wrapper (except of the use of handles and ierror), -- MPI_Recv_f08_nostatus without a status argument. A2. mpi_f08 is defined with BIND(C) routines and explicit names: INTERFACE MPI_Recv(...) SUBROUTINE MPI_Recv_f08(..., status, ...) BIND(C) END SUBROUTINE MPI_Recv_f08_nostatus(..., ...) BIND(C) END END Therefore, the user has also to implement his/her wrappers with SUBROUTINE MPI_Recv_f08(..., status, ...) BIND(C) END SUBROUTINE MPI_Recv_f08_nostatus(..., ...) BIND(C) END or with C routines void MPI_Recv_f08(...., MPI_F_status *status, ....) { .... } void MPI_Recv_f08_nostatus(...., ....) { .... } A3. Same as A2, but the MPI standard defines the C-routine names with other lower/upper-case rules, e.g.: - mpi_recv_f08 and mpi_recv_f08_nostatus to signal to the user of a debugger that this is not a C interface routine (they all use mixed MPI_Xxxx names). - Whether we must use A1 or whether we can freely choose between A1, A2 and A3, depends on whether all routines can be implemented with BIND(C). For this we have to check whether MPI_Op_create can be implemented with BIND(C), which depends on whether the callback routines are also defined with BIND(C) in mpi_f08. For the tools group, it is not a big issue: - With A1, the naming rules are the same for mpif.h & mpi module and for the mpi_f08 module, i.e., according to the Fortran compiler's rule. - With A2 and A3, the naming for mpif.h & mpi module is according to the Fortran compiler's rule and the naming for mpi_f08 with fixed "C-names" (A2: MPI_Recv_f08 / MPI_Recv_f08_nostatus, A3: mpi_recv_f08 / mpi_recv_f08_nostatus) Implication: - It should be mainly decided by the constraints outside the tools world. - But it should be a consistent decision that works for routines with and without callback routines in the argument list. Main decision that we must do: - How must we define -- MPI_Op_create (with a callback with choice buffer), and -- MPI_Errhandler_create (without such a choice buffer callback)? - Main question for this: Which rules do we have for callbacks and BIND(C)? (a full list of all callbacks are in MPI-2.2, page 617) Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Craig Rasmussen" <crasmussen(a)newmexicoconsortium.org> > Cc: "MPI3 Tools" <mpi3-tools(a)lists.mpi-forum.org>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Monday, June 27, 2011 4:24:26 PM > Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools > Hi all, > > I agree with Jeff and Craig - having a TelCon next week > would be helpful. What about Wednesday 7/6 at 8am PDT, > 11am EDT, 5pm MSZ, since this would also give people > from Europe a chance to dial-in. Would this work for > everyone/most of you? Once we have a time, I'll also > send this to the group of tools people we had on the > other email, in case someone wanted to join us. > > Martin > > > On Jun 27, 2011, at 6:42 AM, Rasmussen, Craig wrote: > > > I finally have had a chance to read through all of the responses. > > Hopefully I can clarify a few things without muddying the waters > > further. > > > > If Martin is correct and no tools support the "use mpi" option, then > > things are pretty simple. > > > > 1. mpih.f option: For the immediate future this works as it always > > has. I was only suggesting to deprecate it. But on reconsideration, > > I think this is the wrong thing to do. We are trying to deprecate > > mpih.f itself so the tools using mpih.f can continue using the > > current > > naming convention as long as mpih.f stays around. Fortran users > > could > > write an MPI_Send routine and it would work with the PMPI interface > > as > > before (at least as I understand how this works). > > > > 2. use mpi or use mpi_f08 option: We would mandate that these > > interfaces supply the names mpi_send_f, mpi_send_f_nostatus, > > mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a > > Fortran user want to use the PMPI interface. I need to understand > > this more and write some tests and examples we can all look at. > > > > So I suggest we schedule a conference call sometime next week (after > > July 5). > > > > -craig > > > > > > On Mon, Jun 27, 2011 at 6:38 AM, Hubert Ritzdorf > > <Hubert.Ritzdorf(a)emea.nec.com> wrote: > >> > >> > >>> -----Original Message----- > >>> From: mpi3-fortran-bounces(a)lists.mpi-forum.org > >>> [mailto:mpi3-fortran- > >>> bounces(a)lists.mpi-forum.org] On Behalf Of Bill Long > >>> Sent: Saturday, June 25, 2011 11:33 AM > >>> To: Martin Schulz > >>> Cc: MPI3 Tools; MPI-3 Fortran working group > >>> Subject: Re: [MPI3 Fortran] MPI function symbol naming convention > >>> for tools > >>> > >>> > >>> > >>> On 6/24/11 11:54 AM, Martin Schulz wrote: > >>> > >>>> > >>>> This is probably my lack of knowledge in Fortran compilers, but > >>>> is this all even possible with regular compilers: I would assume > >>>> that you can use an MPI 3.0 implementation with Craig's proposal > >>>> (case A) with an older F77 or F90 compiler, right? If so, one > >>>> would > >>>> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name > >>>> mapping from mpi_send to mpi_send_f - I thought this was a new > >>>> feature from F08? > >>>> > >>> > >>> If you still have an old f77 compiler on you system (from decades > >>> ago), > >>> it will not be adequate. If you have a current version of a > >>> Fortran > >>> compiler available, you are in much better shape. The meaning of > >>> "Fortran" changes over time, and the compilers progress > >>> accordingly, > >>> with some time delay. > >>> > >>> The name mapping of a call to MPI_send into a call to mpi_send_f > >>> is > >>> accomplished with generic interfaces. These were part of Fortran > >>> 90 (20 > >>> year old technology now) - F08 is not required for this. Other > >>> details > >>> of the interfaces do require more recent standards, however. > >>> > >>> > >> > >> Craig's proposal would require at least Fortran 2003. Otherwise, > >> the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_ > >> or > >> mpi_send_f__. > >> > >> Hubert > >> > >> _______________________________________________ > >> mpi3-fortran mailing list > >> mpi3-fortran(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > >> > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: Allmandring 30)

1 0

[MPI3 Fortran] Accepted: MPI-3 Fortran WG
by Lionel, Steve 29 Jun '11

29 Jun '11

1 0

[MPI3 Fortran] MPI-3 Fortran WG
by Jeff Squyres (jsquyres) 29 Jun '11

29 Jun '11

Discuss results of Fortran standards body meeting (from week of June 27), Craig's proposal for standard symbol names, backwards compatibility ramifications, PMPI issues, and implications for MPI tools. ----- WebEx Invite ----- Meeting Number: 201297528 Password: fortran ------------------------ To join the meeting online ------------------------ 1. Go to https://cisco.webex.com/cisco/j.php?ED=168240732&UID=0&PW=NNjkzNTNjYWY4&RT=… 2. Enter your name and email address. 3. Enter the meeting password: fortran 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that appear on your screen. ------------------------ To join the teleconference only ------------------------ 1. Dial into Cisco WebEx - view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 Access code: 201297528 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session.

1 0

[MPI3 Fortran] Fortran WG teleconf
by Jeff Squyres 27 Jun '11

27 Jun '11

Please indicate your availability here: http://www.doodle.com/a3fbkpxca9nbgksh Thanks. -- 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: [MPI3 Fortran] MPI function symbol naming convention for tools
by Martin Schulz 27 Jun '11

27 Jun '11

Hi all, I agree with Jeff and Craig - having a TelCon next week would be helpful. What about Wednesday 7/6 at 8am PDT, 11am EDT, 5pm MSZ, since this would also give people from Europe a chance to dial-in. Would this work for everyone/most of you? Once we have a time, I'll also send this to the group of tools people we had on the other email, in case someone wanted to join us. Martin On Jun 27, 2011, at 6:42 AM, Rasmussen, Craig wrote: > I finally have had a chance to read through all of the responses. > Hopefully I can clarify a few things without muddying the waters > further. > > If Martin is correct and no tools support the "use mpi" option, then > things are pretty simple. > > 1. mpih.f option: For the immediate future this works as it always > has. I was only suggesting to deprecate it. But on reconsideration, > I think this is the wrong thing to do. We are trying to deprecate > mpih.f itself so the tools using mpih.f can continue using the current > naming convention as long as mpih.f stays around. Fortran users could > write an MPI_Send routine and it would work with the PMPI interface as > before (at least as I understand how this works). > > 2. use mpi or use mpi_f08 option: We would mandate that these > interfaces supply the names mpi_send_f, mpi_send_f_nostatus, > mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a > Fortran user want to use the PMPI interface. I need to understand > this more and write some tests and examples we can all look at. > > So I suggest we schedule a conference call sometime next week (after July 5). > > -craig > > > On Mon, Jun 27, 2011 at 6:38 AM, Hubert Ritzdorf > <Hubert.Ritzdorf(a)emea.nec.com> wrote: >> >> >>> -----Original Message----- >>> From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:mpi3-fortran- >>> bounces(a)lists.mpi-forum.org] On Behalf Of Bill Long >>> Sent: Saturday, June 25, 2011 11:33 AM >>> To: Martin Schulz >>> Cc: MPI3 Tools; MPI-3 Fortran working group >>> Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools >>> >>> >>> >>> On 6/24/11 11:54 AM, Martin Schulz wrote: >>> >>>> >>>> This is probably my lack of knowledge in Fortran compilers, but >>>> is this all even possible with regular compilers: I would assume >>>> that you can use an MPI 3.0 implementation with Craig's proposal >>>> (case A) with an older F77 or F90 compiler, right? If so, one would >>>> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name >>>> mapping from mpi_send to mpi_send_f - I thought this was a new >>>> feature from F08? >>>> >>> >>> If you still have an old f77 compiler on you system (from decades ago), >>> it will not be adequate. If you have a current version of a Fortran >>> compiler available, you are in much better shape. The meaning of >>> "Fortran" changes over time, and the compilers progress accordingly, >>> with some time delay. >>> >>> The name mapping of a call to MPI_send into a call to mpi_send_f is >>> accomplished with generic interfaces. These were part of Fortran 90 (20 >>> year old technology now) - F08 is not required for this. Other details >>> of the interfaces do require more recent standards, however. >>> >>> >> >> Craig's proposal would require at least Fortran 2003. Otherwise, the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_ or >> mpi_send_f__. >> >> Hubert >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >> ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [MPI3 Fortran] MPI function symbol naming convention for tools
by Jeff Squyres 27 Jun '11

27 Jun '11

On Jun 27, 2011, at 9:42 AM, Rasmussen, Craig wrote: > I finally have had a chance to read through all of the responses. > Hopefully I can clarify a few things without muddying the waters > further. > > If Martin is correct and no tools support the "use mpi" option, then > things are pretty simple. > > 1. mpih.f option: For the immediate future this works as it always > has. I was only suggesting to deprecate it. But on reconsideration, > I think this is the wrong thing to do. We are trying to deprecate > mpih.f itself so the tools using mpih.f can continue using the current > naming convention as long as mpih.f stays around. Fortran users could > write an MPI_Send routine and it would work with the PMPI interface as > before (at least as I understand how this works). I don't think we can deprecate mpif.h -- Rolf outlined the reasons why in one of our Chicago Forum meetings (some organizations outlaw the use of *any* "deprecated" interface). Rolf's text from the last meeting had strongly worded language advising people not to use mpif.h, but stopped short of deprecating it. > 2. use mpi or use mpi_f08 option: We would mandate that these > interfaces supply the names mpi_send_f, mpi_send_f_nostatus, > mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a > Fortran user want to use the PMPI interface. I need to understand > this more and write some tests and examples we can all look at. > > So I suggest we schedule a conference call sometime next week (after July 5). That would be good. I think that at least the following should attend (others are welcome, of course): - Craig - Jeff - Rolf - Martin - Hubert I'll post a doodle for scheduling shortly. Note that 4 July is a holiday in the US; many (including me) also take the 5th as vacation to make it a 4-day weekend. -- 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: [MPI3 Fortran] MPI function symbol naming convention for tools
by Rasmussen, Craig 27 Jun '11

27 Jun '11

I finally have had a chance to read through all of the responses. Hopefully I can clarify a few things without muddying the waters further. If Martin is correct and no tools support the "use mpi" option, then things are pretty simple. 1. mpih.f option: For the immediate future this works as it always has. I was only suggesting to deprecate it. But on reconsideration, I think this is the wrong thing to do. We are trying to deprecate mpih.f itself so the tools using mpih.f can continue using the current naming convention as long as mpih.f stays around. Fortran users could write an MPI_Send routine and it would work with the PMPI interface as before (at least as I understand how this works). 2. use mpi or use mpi_f08 option: We would mandate that these interfaces supply the names mpi_send_f, mpi_send_f_nostatus, mpi_send_desc, and mpi_send_desc_nostatus. The problem comes when a Fortran user want to use the PMPI interface. I need to understand this more and write some tests and examples we can all look at. So I suggest we schedule a conference call sometime next week (after July 5). -craig On Mon, Jun 27, 2011 at 6:38 AM, Hubert Ritzdorf <Hubert.Ritzdorf(a)emea.nec.com> wrote: > > >>-----Original Message----- >>From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:mpi3-fortran- >>bounces(a)lists.mpi-forum.org] On Behalf Of Bill Long >>Sent: Saturday, June 25, 2011 11:33 AM >>To: Martin Schulz >>Cc: MPI3 Tools; MPI-3 Fortran working group >>Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools >> >> >> >>On 6/24/11 11:54 AM, Martin Schulz wrote: >> >>> >>> This is probably my lack of knowledge in Fortran compilers, but >>> is this all even possible with regular compilers: I would assume >>> that you can use an MPI 3.0 implementation with Craig's proposal >>> (case A) with an older F77 or F90 compiler, right? If so, one would >>> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name >>> mapping from mpi_send to mpi_send_f - I thought this was a new >>> feature from F08? >>> >> >>If you still have an old f77 compiler on you system (from decades ago), >>it will not be adequate. ï¿½If you have a current version of a Fortran >>compiler available, you are in much better shape. ï¿½The meaning of >>"Fortran" changes over time, and the compilers progress accordingly, >>with some time delay. >> >>The name mapping of a call to ï¿½MPI_send into a call to mpi_send_f ï¿½is >>accomplished with generic interfaces. These were part of Fortran 90 (20 >>year old technology now) - F08 is not required for this. ï¿½Other details >>of the interfaces do require more recent standards, however. >> >> > > Craig's proposal would require at least Fortran 2003. Otherwise, the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_ or > mpi_send_f__. > > Hubert > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >

1 0

Re: [MPI3 Fortran] MPI function symbol naming convention for tools
by Hubert Ritzdorf 27 Jun '11

27 Jun '11

>-----Original Message----- >From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:mpi3-fortran- >bounces(a)lists.mpi-forum.org] On Behalf Of Bill Long >Sent: Saturday, June 25, 2011 11:33 AM >To: Martin Schulz >Cc: MPI3 Tools; MPI-3 Fortran working group >Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools > > > >On 6/24/11 11:54 AM, Martin Schulz wrote: > >> >> This is probably my lack of knowledge in Fortran compilers, but >> is this all even possible with regular compilers: I would assume >> that you can use an MPI 3.0 implementation with Craig's proposal >> (case A) with an older F77 or F90 compiler, right? If so, one would >> use "use mpi" or "mpif.h", i.e., case A.1. Can you do the name >> mapping from mpi_send to mpi_send_f - I thought this was a new >> feature from F08? >> > >If you still have an old f77 compiler on you system (from decades ago), >it will not be adequate. If you have a current version of a Fortran >compiler available, you are in much better shape. The meaning of >"Fortran" changes over time, and the compilers progress accordingly, >with some time delay. > >The name mapping of a call to MPI_send into a call to mpi_send_f is >accomplished with generic interfaces. These were part of Fortran 90 (20 >year old technology now) - F08 is not required for this. Other details >of the interfaces do require more recent standards, however. > > Craig's proposal would require at least Fortran 2003. Otherwise, the compiler may still generate MPI_SEND_F, mpi_send_f, mpi_send_f_ or mpi_send_f__. Hubert

1 0

Re: [MPI3 Fortran] [Mpi3-tools] MPI function symbol naming convention for tools
by Hubert Ritzdorf 27 Jun '11

27 Jun '11

It's not simply a re-compilation if you add all interface descriptions to mpif.h in order to change the interface names. In addition to the backward compatibility problem, nobody can guarantee that the re-compilation works independent on compiler bugs or other problems. Hubert >-----Original Message----- >From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:mpi3-tools- >bounces(a)lists.mpi-forum.org] On Behalf Of Jeff Squyres >Sent: Friday, June 24, 2011 6:46 PM >To: MPI-3 Fortran working group >Cc: MPI3 Tools >Subject: Re: [Mpi3-tools] [MPI3 Fortran] MPI function symbol naming >convention for tools > >On Jun 24, 2011, at 12:20 PM, Hubert Ritzdorf wrote: > >> There are (compiled) libraries and object files containing the >corresponding external references to MPI_SEND, mpi_send__, mpi_send_ or >mpi_send. Therefore, you cannot simply change the interface of the MPI_Send >routine without breaking these libraries. You can also not simply expect >that they will be recompiled. > >I think it is reasonable to ask applications / libraries / etc. to >recompile with MPI-3. This has been the position of the Forum. > >> In addition, the mpif.h include file doesn't have an interface block (and >will still generate the external references above) > >It's actually not specified, right? Meaning that an implementation *could* >use an interface block if they wanted to. > >> and Fortran 90 module doesn't have an optional error argument in the >interface block even if you expect that the Fortran 90 module/compiler >supports some NO_ARG_CHECK attribute. > >We didn't add optional arguments to any of the existing MPI Fortran >interfaces -- optional arguments are only (possibly) being added in the new >F08 bindings. > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > > >_______________________________________________ >Mpi3-tools mailing list >Mpi3-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > Click >https://www.mailcontrol.com/sr/Jbc2kOnwVUbTndxI!oX7UlK7uOqmL!e8+HsCtP1TxJlQ >6Ug9oI5ig5!3Uqc1BfKxnNutHdm6V!yFfmYpsSvVwQ== to report this email as spam.

1 0