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

Re: [MPI3 Fortran] MPI function symbol naming convention for tools
by Rasmussen, Craig E 08 Jul '11

08 Jul '11

On Jun 30, 2011, at 2:48 PM, Rolf Rabenseifner wrote: 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) Hopefully not we can move on to solving these final issues. -craig

1 0

Re: [MPI3 Fortran] Incorporating input to naming convention
by Rasmussen, Craig E 08 Jul '11

08 Jul '11

Unless I hear major complaints, my goal is to change my Open MPI implementation to take these changes into account. -craig On Jul 8, 2011, at 8:39 AM, Rasmussen, Craig E wrote: > I've put together a proposed solution to the MPI-3 naming convention for Fortran that incorporates input for emails and discussions over the past few days. Jeff and I had a long conversation yesterday and I was able to read Rolf's email from June 30. > > As Rolf points out, there has to be two naming conventions, one for existing compilers and one for compilers implementing the Interop TR (TR29113) as explained in detail below. Plus there are the existing interfaces for mpif.h and use-mpi. These will be left without changes. > > 1. Interface and naming convention for existing compilers. MPI handles will have the BIND(C) attriburte. But the procedures do not contain the BIND attribute and therefore the binding label is compiler dependent (as we have with existing interfaces). All MPI names will have the suffix "_f08" attached. C implementations will support contiguous choice buffer arguments as they currently do. Example: > > interface MPI_Recv > > subroutine MPI_Recv_f08(buf, ...) ! binding labels will be MPI_RECV_F08, mpi_recv_f08, mpi_recv_f08_, mpi_recv_f08__, ... > ! use ignore TKR directive if possible for buf, overloaded functions for MPI numeric types otherwise > end subroutine > > end interface > > A PMPI user may override this interface in Fortran with: > > subroutine MPI_Recv_f08(buf, ...) > ! ... > call PMPI_Recv_f08(buf, ...) > end subroutine > > > 2. Interface and naming convention for TR29113 compliant compilers. MPI handles will have the BIND(C) attriburte. Procedures will contain the BIND attribute with a binding label. This is required to allow descriptors to be passed to C. All MPI names use the MPI C naming convention (mixed case) and will have the suffix "_f08" attached. C implementations will have to support descriptors for choice buffers and character strings. Example: > > interface MPI_Recv > > subroutine MPI_Recv_f08(buf, ...) BIND(C, name="MPI_Recv_f08") > TYPE(*), DIMENSION(..) :: buf > end subroutine > > end interface > > A PMPI user may override this interface in Fortran with: > > subroutine MPI_Recv_f08(buf, ...) BIND(C, name="MPI_Recv_f08") > ! ... > call PMPI_Recv_f08(buf, ...) > end subroutine > > > Further notes: > > 1. Users won't see a difference as compilers begin to TR29113. They modify there codes to: > a. Use typed handles, e.g., TYPE(MPI_Comm) > b. Use Fortran character strings (as they do now). > c. Call MPI procedures using normal conventions, e.g., CALL MPI_Recv(buf, ...) > > 2. The mixed case name for the binding label for TR29113 interfaces cannot be all lower case as it will collide with possible binding labels for non TR29113 compliant compilers. > > 3. For overloaded functions an additional suffix is applied to the binding label: _nostatus, _noweights, ... > > 4. While an interim solution is required (interfaces in #1 above), it will be allowed to die a natural death as compilers begin to implement TR29113. Eventually there will be a time when C tool writers won't have to deal with the multiple symbol madness that currently exists. There will be two C names to implement, e.g., MPI_Recv_f08, MPI_Recv_f08_nostatus. Again regular MPI users won't notice the change. > > 5. I believe this meets Rolf's 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 > > However I've included wrappers using binding labels like MPI_Recv_f08. This standardized name is absolutely required to write portable code for compilers that implement TR29113. > > Cheers, > Craig > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

[MPI3 Fortran] Incorporating input to naming convention
by Rasmussen, Craig E 08 Jul '11

08 Jul '11

I've put together a proposed solution to the MPI-3 naming convention for Fortran that incorporates input for emails and discussions over the past few days. Jeff and I had a long conversation yesterday and I was able to read Rolf's email from June 30. As Rolf points out, there has to be two naming conventions, one for existing compilers and one for compilers implementing the Interop TR (TR29113) as explained in detail below. Plus there are the existing interfaces for mpif.h and use-mpi. These will be left without changes. 1. Interface and naming convention for existing compilers. MPI handles will have the BIND(C) attriburte. But the procedures do not contain the BIND attribute and therefore the binding label is compiler dependent (as we have with existing interfaces). All MPI names will have the suffix "_f08" attached. C implementations will support contiguous choice buffer arguments as they currently do. Example: interface MPI_Recv subroutine MPI_Recv_f08(buf, ...) ! binding labels will be MPI_RECV_F08, mpi_recv_f08, mpi_recv_f08_, mpi_recv_f08__, ... ! use ignore TKR directive if possible for buf, overloaded functions for MPI numeric types otherwise end subroutine end interface A PMPI user may override this interface in Fortran with: subroutine MPI_Recv_f08(buf, ...) ! ... call PMPI_Recv_f08(buf, ...) end subroutine 2. Interface and naming convention for TR29113 compliant compilers. MPI handles will have the BIND(C) attriburte. Procedures will contain the BIND attribute with a binding label. This is required to allow descriptors to be passed to C. All MPI names use the MPI C naming convention (mixed case) and will have the suffix "_f08" attached. C implementations will have to support descriptors for choice buffers and character strings. Example: interface MPI_Recv subroutine MPI_Recv_f08(buf, ...) BIND(C, name="MPI_Recv_f08") TYPE(*), DIMENSION(..) :: buf end subroutine end interface A PMPI user may override this interface in Fortran with: subroutine MPI_Recv_f08(buf, ...) BIND(C, name="MPI_Recv_f08") ! ... call PMPI_Recv_f08(buf, ...) end subroutine Further notes: 1. Users won't see a difference as compilers begin to TR29113. They modify there codes to: a. Use typed handles, e.g., TYPE(MPI_Comm) b. Use Fortran character strings (as they do now). c. Call MPI procedures using normal conventions, e.g., CALL MPI_Recv(buf, ...) 2. The mixed case name for the binding label for TR29113 interfaces cannot be all lower case as it will collide with possible binding labels for non TR29113 compliant compilers. 3. For overloaded functions an additional suffix is applied to the binding label: _nostatus, _noweights, ... 4. While an interim solution is required (interfaces in #1 above), it will be allowed to die a natural death as compilers begin to implement TR29113. Eventually there will be a time when C tool writers won't have to deal with the multiple symbol madness that currently exists. There will be two C names to implement, e.g., MPI_Recv_f08, MPI_Recv_f08_nostatus. Again regular MPI users won't notice the change. 5. I believe this meets Rolf's 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 However I've included wrappers using binding labels like MPI_Recv_f08. This standardized name is absolutely required to write portable code for compilers that implement TR29113. Cheers, Craig

1 0

Re: [MPI3 Fortran] Notes from conf call on MPI function symbol naming convention for tools
by Rasmussen, Craig E 07 Jul '11

07 Jul '11

On Jul 7, 2011, at 11:29 AM, Bill Long wrote: > > > On 7/7/11 11:48 AM, Rasmussen, Craig E wrote: >> Yesterday we had a conference call on the symbol naming convention for PMPI usage and tools. There are two proposals on the table that we need to discuss and I'd ultimately like to take a straw vote on. I'll try to present the two alternatives along with pros and cons for each choice. For each choice I'll show portions of the interface declaration. >> >> Alternative 1: >> >> interface MPI_Send >> subroutine MPI_Send_f08(...) BIND(C,name="mpi_send_f08") >> use mpi_f08 >> ... >> end subroutine >> end interface >> > > This scheme seems to make sense, assuming rational things are > substituted for the ... omissions. Since the mane=" " specifier > specifies the name that would be used anyway if there were no name= > specifier, the name= part is not really required. However, it is useful > as documentation for readers who don't know Fortran very well. > > >> Synopsis: This method provides a well-known and fixed binding name. >> >> Pros: This method provides a well-known and fixed binding name. Thus C and Fortran PMPI and tools implementors will have a fixed C name (and thus symbol) to bind to. >> >> Cons: This method won't work for all compilers until they implement the interop TR. The reason is that compilers will reject the TYPE(*), DIMENSION(..) syntax as well as character strings in a BIND(C) procedure. However, it turns out most compilers support this interface using some kind of IGNORE TKR compiler directive, though wrapper functions for character strings would have to be used until the TR is implemented. >> >> This choice will force Fortran users of PMPI to use the BIND attribute and C name. >> >> >> Alternative 2: >> >> interface >> subroutine MPI_Send_f08(...) >> use mpi_f08 >> ... >> end subroutine >> end interface >> > > I don't understand this. I expect that the user wants to call MPI_Send > in his program. This works fine with Alternative 1. But here, it looks > like the user has to explicitly call MPI_Send_f08, since there is no > generic MPI_Send name available. This seems like a big negative for > Alternative 2. Sorry, I messed up. The interface for alternative 2 should have a name, as in interface MPI_Send subroutine MPI_Send_f08(...) end subroutine end interface > > >> Synopsis: This method has no C binding. >> >> Pros: It can be implemented now with existing compilers. Fortran users of PMPI don't have to use the BIND attribute and get the C name correct. >> >> Cons: It forces MPI vendors to use non-standard binding names. However, they (and tools people) have been doing this for years so this is a solved problem if not very elegant. The biggest problem with this that when the TR is implemented, the BIND attribute will have to be used so that descriptors will be passed to the implementing routine. The Fortran PMPI users will now have to start using the BIND attribute and the C binding label will be non-standard. For example: >> >> subroutine MPI_Send_f08(...) BIND(C, name="mpi_send_f08__) >> > > This misses the whole point of bind(c). If you are calling a C > function from Fortran, the caller should have a bind(c) interface for > the C function and the binding label should match name in the C > function. If you are calling another Fortran procedure, you do not need > to specify bind(c) in the interface. This problem is rather involved. We are trying to provide hooks for tool writers so that they can intercept the MPI calls, perhaps start some timing routines, then call the PMPI_Send() which calls the "real" MPI implementation. If this is still confusing, I'll call you and we can talk it out. So it is really about providing hooks to the tool writers and so is more involved that simple interfaces to C routines. I think we have worked out those details for the MPI-3 standard. Now we are on to satisfying the tools folk which is mainly about what symbols they see. -craig

1 0

Re: [MPI3 Fortran] Notes from conf call on MPI function symbol naming convention for tools
by Bill Long 07 Jul '11

07 Jul '11

On 7/7/11 11:48 AM, Rasmussen, Craig E wrote: > Yesterday we had a conference call on the symbol naming convention for PMPI usage and tools. There are two proposals on the table that we need to discuss and I'd ultimately like to take a straw vote on. I'll try to present the two alternatives along with pros and cons for each choice. For each choice I'll show portions of the interface declaration. > > Alternative 1: > > interface MPI_Send > subroutine MPI_Send_f08(...) BIND(C,name="mpi_send_f08") > use mpi_f08 > ... > end subroutine > end interface > This scheme seems to make sense, assuming rational things are substituted for the ... omissions. Since the mane=" " specifier specifies the name that would be used anyway if there were no name= specifier, the name= part is not really required. However, it is useful as documentation for readers who don't know Fortran very well. > Synopsis: This method provides a well-known and fixed binding name. > > Pros: This method provides a well-known and fixed binding name. Thus C and Fortran PMPI and tools implementors will have a fixed C name (and thus symbol) to bind to. > > Cons: This method won't work for all compilers until they implement the interop TR. The reason is that compilers will reject the TYPE(*), DIMENSION(..) syntax as well as character strings in a BIND(C) procedure. However, it turns out most compilers support this interface using some kind of IGNORE TKR compiler directive, though wrapper functions for character strings would have to be used until the TR is implemented. > > This choice will force Fortran users of PMPI to use the BIND attribute and C name. > > > Alternative 2: > > interface > subroutine MPI_Send_f08(...) > use mpi_f08 > ... > end subroutine > end interface > I don't understand this. I expect that the user wants to call MPI_Send in his program. This works fine with Alternative 1. But here, it looks like the user has to explicitly call MPI_Send_f08, since there is no generic MPI_Send name available. This seems like a big negative for Alternative 2. > Synopsis: This method has no C binding. > > Pros: It can be implemented now with existing compilers. Fortran users of PMPI don't have to use the BIND attribute and get the C name correct. > > Cons: It forces MPI vendors to use non-standard binding names. However, they (and tools people) have been doing this for years so this is a solved problem if not very elegant. The biggest problem with this that when the TR is implemented, the BIND attribute will have to be used so that descriptors will be passed to the implementing routine. The Fortran PMPI users will now have to start using the BIND attribute and the C binding label will be non-standard. For example: > > subroutine MPI_Send_f08(...) BIND(C, name="mpi_send_f08__) > This misses the whole point of bind(c). If you are calling a C function from Fortran, the caller should have a bind(c) interface for the C function and the binding label should match name in the C function. If you are calling another Fortran procedure, you do not need to specify bind(c) in the interface. Cheers, Bill > Note the trailing underscores. So not only will Fortran PMPI users have to add the BIND attribute at sometime in the future, they will have to do it is a non-portable way. For some compilers they will use the BIND attribute, for others not and the binding label will almost always be different. > > > I suppose there is a third alternative: > > The standard would specify alternative 1, but allow implementors the option of providing wrapper functions (as in alternative 2) that call a C function with an interface consistent with alternative 1 (in the interim until all compilers implement the Interop TR). > > -craig > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & 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

[MPI3 Fortran] Notes from conf call on MPI function symbol naming convention for tools
by Rasmussen, Craig E 07 Jul '11

07 Jul '11

Yesterday we had a conference call on the symbol naming convention for PMPI usage and tools. There are two proposals on the table that we need to discuss and I'd ultimately like to take a straw vote on. I'll try to present the two alternatives along with pros and cons for each choice. For each choice I'll show portions of the interface declaration. Alternative 1: interface MPI_Send subroutine MPI_Send_f08(...) BIND(C,name="mpi_send_f08") use mpi_f08 ... end subroutine end interface Synopsis: This method provides a well-known and fixed binding name. Pros: This method provides a well-known and fixed binding name. Thus C and Fortran PMPI and tools implementors will have a fixed C name (and thus symbol) to bind to. Cons: This method won't work for all compilers until they implement the interop TR. The reason is that compilers will reject the TYPE(*), DIMENSION(..) syntax as well as character strings in a BIND(C) procedure. However, it turns out most compilers support this interface using some kind of IGNORE TKR compiler directive, though wrapper functions for character strings would have to be used until the TR is implemented. This choice will force Fortran users of PMPI to use the BIND attribute and C name. Alternative 2: interface subroutine MPI_Send_f08(...) use mpi_f08 ... end subroutine end interface Synopsis: This method has no C binding. Pros: It can be implemented now with existing compilers. Fortran users of PMPI don't have to use the BIND attribute and get the C name correct. Cons: It forces MPI vendors to use non-standard binding names. However, they (and tools people) have been doing this for years so this is a solved problem if not very elegant. The biggest problem with this that when the TR is implemented, the BIND attribute will have to be used so that descriptors will be passed to the implementing routine. The Fortran PMPI users will now have to start using the BIND attribute and the C binding label will be non-standard. For example: subroutine MPI_Send_f08(...) BIND(C, name="mpi_send_f08__) Note the trailing underscores. So not only will Fortran PMPI users have to add the BIND attribute at sometime in the future, they will have to do it is a non-portable way. For some compilers they will use the BIND attribute, for others not and the binding label will almost always be different. I suppose there is a third alternative: The standard would specify alternative 1, but allow implementors the option of providing wrapper functions (as in alternative 2) that call a C function with an interface consistent with alternative 1 (in the interim until all compilers implement the Interop TR). -craig

1 0

Re: [MPI3 Fortran] Accepted: MPI-3 Fortran WG
by Jeff Squyres 06 Jul '11

06 Jul '11

Yes, I'm sorry -- I wasn't paying attention to email. We're 40+ mins into the webex. Here's the connect info. If you can't join the webex part (Craig is sharing his desktop so that we can talk through code and stuff), you can just dial in -- scroll down for how to join just the teleconference instructions. Please join my meeting that is currently in progress. Topic: MPI-3 Fortran WG Date: Wednesday, July 6, 2011 Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00) Meeting Number: 201 297 528 Meeting Password: fortran ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/e.php?AT=WMI&EventID=168240732&PW=bd3d510c4b5… 2. Enter your name and email address. 3. Enter the meeting password: fortran 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://cisco.webex.com/cisco/e.php?AT=WMI&EventID=168240732&PW=bd3d510c4b5… ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- 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 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/mc 2. On the left navigation bar, click "Support". You can contact me at: jsquyres(a)cisco.com 1-408-525 0971 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14085256800x201297528# 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, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ On Jul 6, 2011, at 11:18 AM, Hubert Ritzdorf wrote: > Hi, > > die the Webex meeting already start ? If so, sorry I couldnï¿½t connect. > > Hubert > > -----Original Appointment----- > From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Lionel, Steve > Sent: Wednesday, June 29, 2011 2:37 PM > To: MPI-3 Fortran working group > Subject: [MPI3 Fortran] Accepted: MPI-3 Fortran WG > When: Wednesday, July 06, 2011 5:00 PM-6:00 PM (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. > Where: WebEx - 201 297 528 > > > > > > Click here to report this email as spam. << File: ATT00001.c >> > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: [MPI3 Fortran] Accepted: MPI-3 Fortran WG
by Hubert Ritzdorf 06 Jul '11

06 Jul '11

Hi, die the Webex meeting already start ? If so, sorry I couldn't connect. Hubert -----Original Appointment----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Lionel, Steve Sent: Wednesday, June 29, 2011 2:37 PM To: MPI-3 Fortran working group Subject: [MPI3 Fortran] Accepted: MPI-3 Fortran WG When: Wednesday, July 06, 2011 5:00 PM-6:00 PM (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. Where: WebEx - 201 297 528 Click here<https://www.mailcontrol.com/sr/u4nyiRAP65fTndxI!oX7UseyfNgsFvsQKRVn4chd7V+C…> to report this email as spam. << File: ATT00001.c >>

1 0

Re: [MPI3 Fortran] [Mpi3-tools] Comments/Questions on Fortran 08 Bindings
by Jeff Squyres (jsquyres) 02 Jul '11

02 Jul '11

See below. I answered only those which weren't alread answered. Sent from my phone. No type good. On Jul 1, 2011, at 3:14 AM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> wrote: > Dear Martin, > > I gathered some feedback from some of the Scalasca team members on the > proposed changes to profiling with the Fortran 08 interface. > > The Scalasca measurement adapter currently creates the Fortran wrappers > for each of the four name-mangling schemes automatically (CPP macros), > as the wrapper is the same, just the symbol name is different. Another > name-mangling scheme for the same wrapper would probably not hurt very much. > > However, some questions arose in the discussions that I have to admit > might stem from our limited knowledge of Fortran and Fortran 08 in > particular. > > 1) Are the Fortran handle types compatible/interchangeable with the C > handle types, or will c2f/f2c still have to be called? > You will still need to call c2f/f2c. MPI f08 handles != MPI mpif or use MPI handles, and != C handles. > 2) Just as John Mellor-Crummey commented: are there standardized > routines to handle the array descriptors in C and C++ which are the > primary languages to implement a measurement layer? If not, how to deal > with it? Can it be interpreted as a void*? How to compare against > MPI_BOTTOM? > > 3) If the Fortran 08-C/C++ interface for the descriptors is not > available. Does it mean I have to implement the wrappers in Fortran? No. > Didn't we just agree that MPI_T does not need Fortran bindings? In this > case it would need them again, right? No. > 4) How is the support for '_f' for just the MPI functions to be done in > the Fortran compiler? Won't it be mangled to '_f_' or '_f__' again? What > are the actual benefits of this '_f'? > There will only be one symbol tools need to worry about: _f. If compilers mangle it further, tools won't know or care. > 5) Why deviate from the existing MPI_STATUS_IGNORE in favor of inflating > the API? Is there a real need for it? > > I can easily imagine users of the Fortran 08 interface, while fixing > some older MPI code written with the Fortran 77 interface, to get > confused about the (in 77) non-optional status parameter. > > 7) Along the lines of Todd's comment on function overloading: It would > be great if the _f08 and _f09_nostatus could just be the same > measurement wrapper, to keep maintenance of measurement code to a minimum. > > Cheers, > Marc-Andre > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52056 Aachen | Germany > > Tel +49 241 80 99753 > Fax +49 241 80 6 99753 > Web www.grs-sim.de > > Members: Forschungszentrum Jülich GmbH | RWTH Aachen University > Registered in the commercial register of the local court of > Düren (Amtsgericht Düren) under registration number HRB 5268 > Registered office: Jülich > Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

Re: [MPI3 Fortran] [Mpi3-tools] Comments/Questions on Fortran 08 Bindings
by Martin Schulz 02 Jul '11

02 Jul '11

Hi Marc-Andre, Thanks for gathering the input - this is helpful. I have cc-ed the Fortran WG on this reply, since all of the questions are directed to them. Hopefully we can clarify some of this during the TelCon on Wednesday - I hope and/or some other people from JSC can make it. Martin On Jul 1, 2011, at 1:14 AM, Marc-Andre Hermanns wrote: > Dear Martin, > > I gathered some feedback from some of the Scalasca team members on the > proposed changes to profiling with the Fortran 08 interface. > > The Scalasca measurement adapter currently creates the Fortran wrappers > for each of the four name-mangling schemes automatically (CPP macros), > as the wrapper is the same, just the symbol name is different. Another > name-mangling scheme for the same wrapper would probably not hurt very much. > > However, some questions arose in the discussions that I have to admit > might stem from our limited knowledge of Fortran and Fortran 08 in > particular. > > 1) Are the Fortran handle types compatible/interchangeable with the C > handle types, or will c2f/f2c still have to be called? > > 2) Just as John Mellor-Crummey commented: are there standardized > routines to handle the array descriptors in C and C++ which are the > primary languages to implement a measurement layer? If not, how to deal > with it? Can it be interpreted as a void*? How to compare against > MPI_BOTTOM? > > 3) If the Fortran 08-C/C++ interface for the descriptors is not > available. Does it mean I have to implement the wrappers in Fortran? > Didn't we just agree that MPI_T does not need Fortran bindings? In this > case it would need them again, right? > > 4) How is the support for '_f' for just the MPI functions to be done in > the Fortran compiler? Won't it be mangled to '_f_' or '_f__' again? What > are the actual benefits of this '_f'? > > 5) Why deviate from the existing MPI_STATUS_IGNORE in favor of inflating > the API? Is there a real need for it? > > I can easily imagine users of the Fortran 08 interface, while fixing > some older MPI code written with the Fortran 77 interface, to get > confused about the (in 77) non-optional status parameter. > > 7) Along the lines of Todd's comment on function overloading: It would > be great if the _f08 and _f09_nostatus could just be the same > measurement wrapper, to keep maintenance of measurement code to a minimum. > > Cheers, > Marc-Andre > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52056 Aachen | Germany > > Tel +49 241 80 99753 > Fax +49 241 80 6 99753 > Web www.grs-sim.de > > Members: Forschungszentrum Jï¿½lich GmbH | RWTH Aachen University > Registered in the commercial register of the local court of > Dï¿½ren (Amtsgericht Dï¿½ren) under registration number HRB 5268 > Registered office: Jï¿½lich > Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes > > <smime.p7s>_______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0