March 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Tools meeting Monday Oct 3
by Rasmussen, Craig E 03 Aug '13

03 Aug '13

On Oct 3, 2011, at 9:26 AM, Rasmussen, Craig E wrote: We have potential problem going to C for character strings and optional arguments. # Symbols for mpif.h and use mpi # define MPI_SEND_NAMEMANGLING_TR 0 # MPI_SEND mpi_send mpi_send_ mpi_send__ #define MPI_SEND_NAMEMANGLINE_TR 1 MPI_Send_f # has choice buffer as array descriptor # Symbols for use mpi_f08 (not using the new interop TR) # define MPI_SEND_NAMEMANGLINE_TR 0 # MPI_SEND_f08 mpi_send_f08 mpi_send_f08_ mpi_send_f08__ # define MPI_SEND_NAMEMANGLING_TR 1 # MPI_Send_f08 # has choice buffer as array descriptor

2 2

Re: [MPI3 Fortran] [Mpi3-tools] Questions on the F2008 profiling interface issues
by Rolf Rabenseifner 02 Aug '13

02 Aug '13

Dear all, according to pages:lines in https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… and the decision of the Santorini 2011 meeting, we should add the following text to accommodate the tools implementors. P559:20-21 reads equals .FALSE.. If but should read equals .FALSE., and After p559 the following text should be added: ---------------------------- To simplify the development of profiling libraries, the MPI routines are grouped together and it is required that if the peer routine of a group is available within an MPI library with one of its possible linker names then all of the routines in this group must be also provided according to the same linker name scheme, and if the peer routine is not available through a linker name scheme then all other routines have also not to be available through this scheme. Peer routines and their groups: - MPI_ALLOC_MEM MPI_ALLOC_MEM and MPI_WIN_ALLOCATE. - MPI_FREE_MEM Only this routine is in this group. - MPI_GET_ADDRESS MPI_GET_ADDRESS and MPI_ADDRESS. - MPI_SEND All routines with choice buffer arguments that are not declared as ASYNCHRONOUS within the mpi_f08 module and exist already in MPI-2.2. - MPI_NEIGHBOR_ALLTOALL All routines with choice buffer arguments that are not declared as ASYNCHRONOUS within the mpi_f08 module and are new in MPI-3.0. - MPI_ISEND All routines with choice buffer arguments that are declared as ASYNCHRONOUS within the mpi_f08 module and exist already in MPI-2.2. - MPI_IBCAST All routines with choice buffer arguments that are declared as ASYNCHRONOUS within the mpi_f08 module and are new in MPI-3.0. - MPI_OP_CREATE Only this routine is in this group. - MPI_REGISTER_DATAREP Only this routine is in this group. - MPI_COMM_KEYVAL_CREATE All other routines with callback function arguments. - MPI_COMM_DUP_FN All predefined callback routines. - MPI_COMM_RANK All other MPI routines that exist already in MPI-2.2. - MPI_IBARRIER All other MPI routines that are new in MPI-3.0. Advice to implementors. If all the following conditions are fulfilled (which is the case for most compilers) - the handles in the mpi_f08 module occupy one Fortran numerical storage unit (same as an INTEGER handle), and - the internal argument passing used to pass an actual ierror argument to a non optional ierror dummy argument is binary compatible to passing an actual ierror argument to an ierror dummy argument that is declared as OPTIONAL, and - the internal argument passing for ASYNCHRONOUS and non-ASYNCHRONOUS arguments is the same, and - the internal routine call mechanism is the same for the Fortran and the C compiler, and - the compiler does not provide TR 29113, then for most groups, the implementor may use the same internal routine implementations for all Fortran support methods with only different linker names. For TR 29113 quality, new routines are needed only for the routine groups of MPI_ISEND and MPI_IBCAST. End of advice to implementors. ---------------------------- Not directly relevant for the tools people, but giving the reason for differentiating several Choice-buffer routine groups, the following changes are also done: P552:14-18 read - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to .TRUE. and declare choice buffers using the Fortran 2008 TR 29113 feature assumed-type and assumed-rank, i.e., TYPE(*), DIMENSION(..), if the underlying Fortran compiler supports it. With this, non-contiguous sub-arrays can be used as buffers in nonblocking routines. but should read - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to .TRUE. and declare choice buffers using the Fortran 2008 TR 29113 feature assumed-type and assumed-rank, i.e., TYPE(*), DIMENSION(..) in all nonblocking, split collective and persistent communication routines, if the underlying Fortran compiler supports it. With this, non-contiguous sub-arrays can be used as buffers in nonblocking routines. Rationale. In all blocking routines, i.e., if the choice-buffer is not declared as ASYNCHRONOUS, the TR 29113 feature is not needed for the support of non-contiguous buffers because the compiler can pass the buffer by in-and-out-copy through a contiguous scratch array. End of rationale. P555:7-10 read - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to .TRUE. if all choice buffer arguments are declared with TYPE(*), DIMENSION(..), otherwise set it to .FALSE.. With MPI_SUBARRAYS_SUPPORTED==.TRUE., non-contiguous subarrays can be used as buers in nonblocking routines. but should read - Set the INTEGER compile-time constant MPI_SUBARRAYS_SUPPORTED to .TRUE. if all choice buffer arguments in all nonblocking, split collective and persistent communication routines are declared with TYPE(*), DIMENSION(..), otherwise set it to .FALSE.. With MPI_SUBARRAYS_SUPPORTED==.TRUE., non-contiguous subarrays can be used as buers in nonblocking routines. I'll try to be at the tel-con today. Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> > Cc: "MPI3 Tools" <mpi3-tools(a)lists.mpi-forum.org>, "Martin Schulz" <schulz6(a)llnl.gov>, "Craig E Rasmussen" > <rasmussn(a)lanl.gov>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "Jeff Squyres" <jsquyres(a)cisco.com>, "Andreas > Knüpfer" <andreas.knuepfer(a)tu-dresden.de>, "Todd Gamblin" <tgamblin(a)llnl.gov>, "Tobias Hilbrich" > <tobias.hilbrich(a)tu-dresden.de>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Sunday, October 2, 2011 6:13:46 AM > Subject: Re: [Mpi3-tools] Questions on the F2008 profiling interface issues > Hi Marc-Andre, > > On Sep 30, 2011, at 6:27 AM, Marc-Andre Hermanns wrote: > > > Martin, > > > >> I was in Dresden the last few days (visiting the Vampir group, in > >> particular Andreas Knuepfer and Tobias Hilbrich who are responsible > >> for > >> their MPI wrappers) and we sat down to talk about the issues around > >> the > >> profiling interface in ticket #229. > >> > >> Here is a quick summary with a few questions that came up: > >> > >> * With the new Fortran symbol naming variants, there are 6 or 8 or > >> 10 > >> versions for every MPI subroutine. Tools could intercept all > >> versions by > >> providing own symbols for all versions. > > > > If it is clear which name the symbols have, additional symbol names > > should be easy to generate, so at this stage I think it doesn't > > matter > > much, whether we have 6, 8, or 10 different schemes to cover. Right? > > I agree - as long as we can generate a full list of names, we can > intercept them all. Adding wrappers shouldn't be a problem. > > > > >> Now the problem: Within the wrapper function a tool needs to call > >> the > >> correct PMPI call which usually is the same prefix (either '_f08', > >> '_f', '__' etc.) as the MPI call it is in. A mapping to matching C > >> functions (as most tools do it now) is not possible due to problems > >> with calling conventions for callback routines. > > > > As far as I know our wrappers call the C routines, because we jump > > through all sorts of hoops to get a proper Fortran to C conversion > > and > > back. So in this regard, we need to fix this. Interestingly this has > > not > > popped up yet. > > I agree - this is remarkable. > > > > > If we write Fortran wrappers in Fortran, how would a Fortran wrapper > > compiled with Fortran 77 have to call the C measurement code inside > > the > > wrapper? If the Fortran compiler implicitly adds underscores to the > > calls, do I have to provide a special Fortran interface to my > > measurement system then? > > That is a question for the Fortran experts. > > > > >> * Would the following solution work? All wrappers for Fortran are > >> written > >> in Fortran instead of C. > >> [...] > >> For every MPI function, there are 6 or 8 variants and all of them > >> need to be provided by a tool. This would probably mean that we > >> have > >> to compile wrappers with all three calling conventions (mpif.h, use > >> mpi_f and use mpi_f08) and then link them together? > > > > Don't we need to compile with all three calling conventions on all > > possible compilers on a given system? > > Also, here, I think the Fortran experts need to weigh in. > > > > > We currently provide all 4 name-mangling schemes with every install > > of > > Scalasca, because we had some issues with applications using two > > different Fortran compilers for different sub-modules. (This came up > > in > > a project some years back, and ever since then we provide all > > schemes in > > the same library and it seems to work.) > > > >> * As discussed at the forum, if we want to keep our tools in C > >> (which is > >> probably still the easier and better option), we need to know the > >> symbols > >> on the "p" side and we need a portable way to figure this out. We > >> talked > >> about the solution of two groups of routines - one for which we > >> have _f08 > >> symbols for one for which we don't. Rolf, how will you add this to > >> the > >> standard, in particular how will you form those groups. > > > > I started to get some doubts about this approach. One of the issues > > was > > that some choice-buffer routines had names longer than the proposed > > limit. So they need to be mangled differently, especially, their > > symbol > > needs to be shortened. And as I understood it, the current idea is > > to > > leave it to the MPI implementation to define the shortened name. > > I thought that was just for the argument checking in mpif.h and that > we decided to not support this. Are there more locations were the > names are too long? > > > > > It is one thing, finding out which suffix is used. Finding how > > function > > names are mangled without any form of restricting to possible > > schemes > > seems to be another ball game? > > > > Am I missing something? > > Yes, if we do have to shorten names, I agree - I think, though, we got > around the issue, or did we not? > > > > > I think, as it was pointed out in Santorini with the Fortran > > Bindings in > > general, we (or at least I) don't have enough Fortran expertise to > > think > > this through all to the end and consider all implications. I think > > it > > would be a great benefit to have people of the Fortran WG to join on > > the > > call on Monday. I hope this is possible. > > Yes, that would be great - all are cc-ed. > > Martin > > > > > > 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 > > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA -- 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)

2 2

Re: [MPI3 Fortran] [Mpi3-tools] Questions on the F2008 profiling interface issues
by Martin Schulz 02 Aug '13

02 Aug '13

Hi Rolf, Sorry, this must have gone lost in the long email trail. All the meeting information is on the tools Wiki at: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools I know the holiday is a problem, but I couldn't see an option on how to avoid this since moving it to next week would have been too late to provide feedback in time. It would be great if you could make it anyway. Otherwise, any feedback by email would be great as well, in particular on the grouping of _f08 functions we talked about during the last forum. Thanks, Martin On Oct 2, 2011, at 2:15 PM, Rolf Rabenseifner wrote: > >>> I think it >>> would be a great benefit to have people of the Fortran WG to join on >>> the call on Monday. I hope this is possible. >> >> Yes, that would be great - all are cc-ed. > > What must I do? > Can you provide date, time, number? > Oct. 3 is a holiday in Germany, therefore, I'm nut sure > that I can join. > > Rolf > > > -- > 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) ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

4 3

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Rolf Rabenseifner 29 Mar '13

29 Mar '13

We (Jeff, Bill L., Craig, Hubert, Martin, Tobias, and me (Rolf)) had a telecon today and the outcome are following options: Option 1 - #364 as it currently is, as a minimal solution for the LOGICAL problem: Pro: It is consistent between Fortran and MPI. I.e., it is the minimal solution that we must do. Con: It has a mix of BIND(C) and non-BIND(C) routine groups which is ugly for the future. Remark: non-BIND(C) will stay there because the callbacks need non-BIND(C) in the moment and this cannot be changed in the future by nice new concepts from the Fortran language standardization. Option 2 - #364 plus changing MPI-3.0 page 605 lines 24-30 and page 605 line 47 - page 606 line 6 by also using non-BIND(C), but other linker names: MPI_Send_f08d (in mpi_f08 with TS29113 quality, i.e., buffers are done with C-descriptors and not with void* pointers.) MPI_Send_fd (in the mpi module or mpif.h if MPI_SUBARRAYS_SUPPORTED=.TRUE. is also done there, i.e., with the descriptors.) Pro: It is consistent between Fortran and MPI and it is consistent within MPI, i.e., all functionality is done with non-BIND(C) routines. BIND(C) can be still used internally to call MPI_Send_cdesc and MPI_Isend_cdesc. To be fair, implementatiosn will be based mainly on this TS 29113 feature, but only internally. Con: No BIND(C) on the official MPI interface. We urged Fortran to put some features into TS 29113, but we will not use these features, because they are not needed on this internal interface. Option 3: - Option 2 plus the following rule: - The Fortran PMPI interface can be substituted by a wrapper based sulution that internally calls the full MPI C interface. - In this case, the Fortran interface should be hidden to the tools. - For the buffer routines with the new cdesc descriptor, new interfaces are added for the tools people, e.g., MPI_Send_cdesc and MPI_Isend_cdesc. Pro: I'm not sure whether there is a real pro? Bill, can you add the pros, it is your option. Con: An additional new interface for the tools folk. It is not backward compatible for users who really intercept the Fortran MPI interface. My favorite in the moment, i.e. at the starting of the pro-con-discussion: Option 2. Best regards Rolf ----- Original Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: longb(a)cray.com > Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" > <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, "Tobias Burnus" <burnus(a)net-b.de> > Sent: Monday, March 25, 2013 12:21:39 PM > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > Yes, this freedom (1)-(4) in Bill's email is important. > > In our discussion, we forgot one additional reason why we defined > it as it is written in MPI-3.0 Section 17.1.5, page 605: > > - It should be possible to implement the interfaces with > these non-standard Fortran-void-* directives, > and later on, > to substitute this implementation by new ones > that are based on TS 29113. > - When doing this substitution, it should be save for > applications when the application is not re-compiled. > - More than that, it should be possible to combine older > .o files with newly TS 29113 based .o files. > - For this, we decided, that the implementation has to switch > from non-BIND(C) to BIND(C) at least in the MPI_ISEND > routine group when switching to MPI_SUBARRAYS_SUPPORTED==.TRUE. > - The real trick is that the linker name must be changed. > - This all is valid for both, the new mpi_f08 module, > and the old mpi module. > > A second issue in our discussion is always, which changes > we want to do to the mpi_f08 MPI-3.0 user interface. > I want to remember that this user interface is defined > according following rules. > If a user modifies his source to use everywhere mpi_f08, > he/she has to modify: > - He/she has to substitute the "include 'mpif.h'" or "use mpi" > statements by "use mpi_f08". > - He/she has to modify all handle and status declarations. > - In the executable statements, he/she has to substitute all > status(MPI_TAG), status(MPI_SOURCE), status(MPI_ERROR) > accesses into > status%MPI_TAG, status%MPI_SOURCE, status%MPI_ERROR. > - Callback routines need more effort due to the > abstract interface definitions. > This is touched by ticket #364, i.e., > the MPI-3.0 BIND(C) of callbacks had to be removed. > - Changes in the interfaces are only > -- all handles use the new handle types > and in > -- MPI_User_function, > -- MPI_Datarep_conversion_function, > the buffers are done with TYPE(C_TR), VALUE. > > This should be all. > All other user correct code should directly compile with the new > mpi_f08 module. > We should not change these things, except the necessary > errata in #364. > > I see that we have some freedom only in the area, > what we do internally (together with linker names) and with PMPI, > but not in the user interface. > If we add additional user interfaces (e.g. overloading the LOGICAL > with INTEGER arguments) > we would only make it more complicate. > > Best regards > Rolf > > > ----- Original Message ----- > > From: "Bill Long" <longb(a)cray.com> > > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > > Cc: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com>, "Craig E > > Rasmussen" <rasmus(a)cas.uoregon.edu>, "Hubert Ritzdorf" > > <Hubert.Ritzdorf(a)emea.nec.com>, "Martin Schulz" <schulzm(a)llnl.gov>, > > "Tobias Burnus" <burnus(a)net-b.de> > > Sent: Sunday, March 24, 2013 5:59:38 PM > > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 > > interface - issue with the LOGICAL kind > > This time is OK for me. I'll look for the webex email. > > > > I would like to note that the various options discussed are not > > necessarily "all or nothing" propositions. An implementation could > > use > > the thin wrappers in a module approach to eliminate the bad Fortran > > types problems for most of the MPI routines, but also have some > > routines > > implemented in a different way, such as (1) all in Fortran that is > > callable from C, (2) all in C that is called through an interface > > directly from Fortran, (3) as a fat wrapper in Fortran, or (4) a > > completely replicated routine for the Fortran implementation. There > > is > > no reason that all of the routines have to be the same method - in > > fact > > probably good arguments against that in some cases. We just need to > > have > > the rules such that the tools have some known name to intercept. > > Along > > the lines of "If implementation method X is chosen for routine > > MPI_xxx, > > then these are the linker name requirements:.....". > > > > Cheers, > > Bill > > > > > > > > On 3/23/13 2:11 AM, Rolf Rabenseifner wrote: > > > Dear Jeff, Craig, Bill, Hubert, Martin, and Tobias, > > > > > > I expect that this is the total group that discusses the > > > Fortran LOGICAL etc. problem. > > > We learnt that the solutions also touch the PMPI concept. > > > There was a telecon between Craig, Jeff and Bill with the proposal > > > at the end of this email. > > > I like to understand this proposal and therefore I asked Jeff > > > for explanations. I would like to open this for the whole group. > > > > > >> I have meetings at 9am and 1pm is eastern on Monday. I can talk > > >> any > > >> other time. > > >> Craig prob can't attend because he's 3 hours earlier, but that's > > >> prob ok. > > > > > > Monday March 25, > > > - 4 PM Central European Time CET > > > = 11 AM Eastern Daylight Time EST/EDT > > > = 8 AM Pacific Time > > > > > > I hope these relations are correct. Would this work for you? > > > > > > At least for Jeff and me, because I want to understand > > > what they discussed with their proposal. > > > > > > Jeff, can you set up a webex? > > > > > > Best regards > > > Rolf > > > > > > ----- Original Message ----- > > >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > > >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > > >> Cc: "Craig E Rasmussen" <rasmus(a)cas.uoregon.edu> > > >> Sent: Friday, March 22, 2013 8:01:23 PM > > >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 > > >> interface - issue with the LOGICAL kind > > >> Btw, I'm not sure how this is not the least surprise. > > >> > > >> We can't change the params to not be logical, yes we must still > > >> allow > > >> for calling to c. So the overloaded solution is the only one. > > >> > > >> And the new Integer param signature must have a new bind name so > > >> as > > >> to > > >> did ambiguity it from the one we published in MPI3. See my > > >> previous > > >> mail about this. > > >> > > >> I have meetings at 9am and 1pm is eastern on Monday. I can talk > > >> any > > >> other time. > > >> > > >> Craig prob can't attend because he's 3 hours earlier, but that's > > >> prob > > >> ok. > > >> > > >> Sent from my phone. No type good. > > >> > > >> On Mar 22, 2013, at 8:51 AM, "Rolf Rabenseifner" > > >> <rabenseifner(a)hlrs.de> wrote: > > >> > > >>> Jeff, > > >>> > > >>> can I call you by phone? > > >>> I would like to talk to you as the binding responsible and MPI > > >>> chair. > > >>> > > >>>> 2. Replace the current binding names for MPI functions with > > >>>> LOGICAL > > >>>> dummy arguments with a different name and replacing LOGICAL > > >>>> type > > >>>> with > > >>>> default INTEGER arguments. The name must be changed so as to > > >>>> not > > >>> ... > > >>> This is a hard step and far away from "last surprise". > > >>> > > >>> I would like to learn how it came out as a result of your > > >>> telecon, > > >>> before I try to go the next step (e.g. email answer). > > >>> > > >>> Best regards > > >>> Rolf > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu> > > >>>> To: "MPI-3 Fortran working group" > > >>>> <mpi3-fortran(a)lists.mpi-forum.org> > > >>>> Cc: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com>, "Martin > > >>>> Schulz" <schulzm(a)llnl.gov> > > >>>> Sent: Friday, March 22, 2013 4:29:36 PM > > >>>> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran > > >>>> 2008 > > >>>> interface - issue with the LOGICAL kind > > >>>> > > >>>> Bill Long, Jeff Squyres, and I had a phone conversation > > >>>> yesterday > > >>>> and came up with a straw man proposal. We believe it fixes the > > >>>> LOGICAL argument problem while satisfying three major goals: > > >>>> > > >>>> 1. Backwards compatibility. > > >>>> 2. Flexibility so that efficient implementations can be > > >>>> produced > > >>>> on > > >>>> a variety of hardware. > > >>>> 3. Not dramatically increase the complexity for the tools > > >>>> community. > > >>>> 4. Ensure that the changes won't be seen by ordinary Fortran > > >>>> MPI > > >>>> users. > > >>>> > > >>>> The straw man proposal is: > > >>>> > > >>>> 1. Remove the current binding names for MPI functions with > > >>>> LOGICAL > > >>>> dummy arguments (. This must be done because these interfaces > > >>>> break > > >>>> the Fortran standard. > > >>>> 2. Replace the current binding names for MPI functions with > > >>>> LOGICAL > > >>>> dummy arguments with a different name and replacing LOGICAL > > >>>> type > > >>>> with > > >>>> default INTEGER arguments. The name must be changed so as to > > >>>> not > > >>>> conflict with the current name with LOGICAL arguments. For > > >>>> example, > > >>>> the binding name "MPI_Test_f08" will be replaced by > > >>>> "MPI_Test_int_f08" > > >>>> (exact replacement name open for discussion). The Fortran > > >>>> implementation of the function MPI_Test must call > > >>>> MPI_Test_int_f08 > > >>>> as soon as possible for the tools implementers. > > >>>> 3. Implementation of the Fortran PMPI calling convention will > > >>>> be > > >>>> made optional (we think it already it). If an MPI implementer > > >>>> doesn't > > >>>> provide the MPI_F08 binding names, then it must call the C MPI > > >>>> implementation in a thin Fortran wrapper so that the tools > > >>>> implementers can intercept the call in C. An MPI implementation > > >>>> shall not provide/call both the MPI_F08 binding name and the C > > >>>> name. > > >>>> > > >>>> Option 2 allows some MPI vendors to implement MPI functions > > >>>> entirely within Fortran (using the MPI_f08 binding names), > > >>>> if this is more efficient. > > >>>> > > >>>> Option 3 allows some MPI implementations to place Fortran > > >>>> wrappers > > >>>> inside modules where they may be inlined by the compiler for > > >>>> efficiency. > > >>>> > > >>>> Craig Rasmussen > > >>>> CAS Scientific Programmer > > >>>> rasmus(a)cas.uoregon.edu > > > > > > > -- > > 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 > > -- > 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) -- 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)

7 26

[MPI3 Fortran] Another (smaller) issue with MPI 3.0 and BIND(C)
by Tobias Burnus 25 Mar '13

25 Mar '13

Dear all, there is possible one other problem with some BIND(C) interfaces in MPI 3.0: MPI_Comm_get_name(comm, comm_name, resultlen, ierror) BIND(C) TYPE(MPI_Comm), INTENT(IN) :: comm CHARACTER(LEN=MPI_MAX_OBJECT_NAME), INTENT(OUT) :: comm_nameI Namely, it uses a CHARACTER dummy argument which does not have LEN=1 in a procedure with C binding. From Fortran 2008's "15.3.2 Interoperability of intrinsic types" (p.429, paragraph 1): "If the type is character, the length type parameter is interoperable if and only if its value is one." Initially, I though that the following would allow it: "A named scalar Fortran variable is interoperable if and only if its type and type parameters are interoperable, [...] and if it is of type character its length is not assumed or declared by an expression that is not a constant expression." ("15.3.5 Interoperability of scalar variables", p. 432, paragraph 1.) I thought that the latter part allows it. However, as Bill pointed out: The "if and only if ... type parameters are interoperable" makes clear that it is only interoperable if the length is 1. (The second condition makes only sure that this it is compile-time checking by not allowing len=* or nonconst expressions). TS 29113 allows in addtion len=* and len=: for dummy arguments of BIND(C) procedures. However, that doesn't help for LEN=MPI_MAX_OBJECT_NAME, either. (For len=*/len=:, TS 29113 requires that an array descriptor is used; cf. "8.7 Interoperability of procedures and procedure interfaces", p.31, (6)(b) and the paragraph below (6)(d).). I think the simplest is to change: CHARACTER(LEN=MPI_MAX_OBJECT_NAME), INTENT(OUT) :: comm_nameI to CHARACTER, INTENT(OUT) :: comm_nameI(MPI_MAX_OBJECT_NAME) Namely, to change the character length to 1 and the array size to MPI_MAX_OBJECT_NAME. Using the storage association for characters, a character(len=MPI_MAX_OBJECT_NAME) variable can be passed to a character(len=1) character array of size MPI_MAX_OBJECT_NAME. To quote the standard: "The type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument that are not assumed, except for the case of the character length parameter of a default character or character with the C character kind (15.2.2) actual argument associated with a dummy argument that is not assumed shape. If a scalar dummy argument is default character or of type character with the C character kind, the length len of the dummy argument shall be less than or equal to the length of the actual argument. The dummy argument becomes associated with the leftmost len characters of the actual argument. If an array dummy argument is default character or of type character with the C character kind and is not assumed shape, it becomes associated with the leftmost characters of the actual argument element sequence (12.5.2.11)." (F2008, "12.5.2.4 Ordinary dummy variables", p. 293, paragraphs 3 and 4.) Tobias

3 2

[MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Jeff Squyres (jsquyres) 22 Mar '13

22 Mar '13

MPI Fortran group -- The report below came in from Tobias Burnus / Pathscale because of an issue that arose in the Open MPI implementation of the MPI F08 bindings. What should we do about this? Begin forwarded message: > From: Tobias Burnus <burnus(a)net-b.de> > Subject: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > Date: February 26, 2013 7:19:07 AM EST > To: <mpi-comments(a)lists.mpi-forum.org> > Reply-To: Comments on the MPI Standard <mpi-comments(a)lists.mpi-forum.org> > > Dear all, > > Digest version: The Fortran 2008 interface should use "LOGICAL(kind=C_BOOL)" instead of "LOGICAL". > > > MPI 3 [1] adds a new Fortran 2008 interface (or rather one using Fortran 2008 [2] plus TS 29113 [3]), which uses C binding ("bind(C)"). For instance the following (from "6.7.2 Communicators"): > > ABSTRACT INTERFACE > SUBROUTINE MPI_Comm_copy_attr_function(oldcomm, comm_keyval, extra_state, > attribute_val_in, attribute_val_out, flag, ierror) BIND(C) > TYPE(MPI_Comm) :: oldcomm > INTEGER :: comm_keyval, ierror > INTEGER(KIND=MPI_ADDRESS_KIND) :: extra_state, attribute_val_in, > attribute_val_out > LOGICAL :: flag > > > The code assumes that the default-kind INTEGER and LOGICAL are interoperable. It is very likely that default-kind integers are interoperable, given that C supports many integer types (signed char, short, int, long, long long) and that Fortran's default-kind integer typically matches "int". > > > However, for LOGICAL this is not necessarily the case. Fortran's default-kind LOGICAL is always [5] as wide as the default-kind INTEGER ("LOGICAL(kind=4)"). However, C99's [4] _Bool is on nearly all systems (one exception is 32bit Darwin) only one byte wide (sizeof(_Bool) == 1) [6]. The Fortran standard only defines interoperability with this logical kind: > > > Fortran 2008, "15.2.2 Named constants and derived types in the module": "The value of C_BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1." > > Fortran 2008, "Table 15.2: Interoperability between Fortran and C types": > "Fortran type / Named constant from the ISO C BINDING module (kind type parameter if value is positive) / C type" > ... > "LOGICAL / C_BOOL / _Bool" > > > Hence, a conforming compiler might only accept a single interoperable LOGICAL kind, namely: C_BOOL. That's actually the case for the PathScale/pathf95 compiler ï¿½ and also GCC/gfortran (version >= 4.8) with -std=f2003/f2008/f2008ts only accepts LOGICAL(C_BOOL) but not LOGICAL [7]. > > > Note an additional potential issue: C99's _Bool only allows two values, 0 and 1; see C99's "6.3.1.2 Boolean type": "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." > > At least the GCC makes use of this restriction and sets TYPE_PRECISION to 1 for C99/C++'s _Bool/bool and Fortran's LOGICAL (for all KIND= values). As the hardware typically supports instructions of the form "jump if zero" or "jump if not zero", also other values work in "if (bool_var)". However, for negation (C/C++: "!", Fortran: ".not."), GCC only flips one bit. Hence, for C99's _Bool, C++'s bool and Fortran's LOGICAL (any kind), negating "-2" leads to "-1". > > Example: If you have in one file: > "signed char bool_var = -2; sub(bool_var)" > and in the other file either: > void sub(_Bool bool_var) > or > subroutine sub(bool_var) bind(C) > logical(kind=C_Bool), value :: bool_var > both "bool_var" and "!bool_var"/".not.bool_var" evaluate to true/.true. > > In that sense, Fortran's "LOGICAL :: v" is not interoperable with C's "int v" unless the value is restricted to 0 and 1. > > Note regarding C99: If you assign or cast to _Bool, the compiler ensures that only the value 0 and 1 is used. Additionally, many operations in C99 return an "int", for instance "&&" or "||" do (see C99, "6.5.13 Logical AND operator" and 6.5.14). Thus, in pure C code one does not easily run into this issue. Nor in pure Fortran code as one there typically doesn't mix LOGICAL with INTEGER. But when mixing C and Fortran (or mixes code compiled iwth different compilers [8]), this can lead to wrong code. > > > Hence, I strongly suggest to change in all BIND(C) procedures LOGICAL to LOGICAL(C_Bool). For the three reasons above: (a) the standard only defines interop with kind=C_Bool; (b) pathf95 [and gfortran with -std=f2008ts] only support C_Bool kind logicals with Bind(C); (c) at least with GCC, using default-kind LOGICAL might lead to wrong results if the value is not 0 or 1. > > > Tobias > > PS: The issue came up with Open MPI's bug report https://svn.open-mpi.org/trac/ompi/ticket/3523 > > > [1] MPI 3: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf; erratum http://www.mpi-forum.org/docs/errata-30.pdf > [2] Fortran 2008 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf ; corrigenda 1 & 2: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1903.pdf , ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1958.pdf > [3] TS 29113 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf > [4] C99+TC1,TC2,TC3: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf > [5] That's required in Fortran 2008's "16.5.3.2 Storage sequence": "a nonpointer scalar object that is default integer, default real, or default logical occupies a single numeric storage unit," > [6] That _Bool has is one byte wide is implied by C99's "The rank of _Bool shall be less than the rank of all other standard integer types." (6.3.1.1), but in my reading it does not formally demand it. With GCC, one can force this width for 32bit Darwin via -mone-byte-bool. > [7] Currently, GCC still accepts LOGICAL / LOGICAL(4) with default options (-std=gnu); however, that might change. See discussion at http://gcc.gnu.org/ml/fortran/2013-01/msg00090.html and http://gcc.gnu.org/PR55758 > [8] In particular, Intel's Fortran compiler uses "-1" for .true., independent of logical kind and bind(C); for the reasons outlined above, it thus interacts badly with GCC/gfortran. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

9 105