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

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 14 Mar '13

14 Mar '13

On 3/14/13 4:14 PM, Rolf Rabenseifner wrote: > Dear all, > > I would like to learn > - Who is implementing the new mpi_f08 module > -- for mpich? > Is this you, Bill Long? I've been working under that assumption. > -- for OpenMPI? > Is this you, Craig? > -- who else is currently implementing the > new Fortran mpi_f08 module? > - Do I understand correctly that both implementations: > -- do use Fortran-written wrappers as MPI user-API? I use thin Fortran wrappers that call C functions directly for the 'normal' MPI routines. The wrappers are contained in the module. The implementations of the require defined operators for comparing the new Fortran types are all written in Fortran in the module. The conversion functions between the Fortran and C versions of STATUS structures are all written in Fortran and in the module. (Basically, any part of the implementation that has to understand Fortran types is in Fortran.) > -- I.e., it is simple to change it to BIND(C) or non-BIND(C)? For the normal routines, there is no requirement for BIND(C) on the Fortran wrappers. The interfaces for the C functions do have BIND(C), of course. (I included an example for MPI_Isend in an earlier email - basically the pattern is the same for the others.) In fact, one would like for the compiler to inline, and optimize away the wrapper. In that case, the external name of the wrapper becomes irrelevant since it does not occur in the final executable. Only the name of the C worker function remains as an external. The module procedures that implement the conversions for STATUS do need BIND(C) since it is possible that these would be called from a C function and there is no C version of these routines. > -- I.e., only for the tools people, it is of > interest whether BIND(C) or non-BIND(C) was chosen? > -- What are other implementations do? > > I ask this, to learn whether the BIND(C)/non-BIND(C) freedom > for the implementations can/should be reduced > to make life easier. Having more freedom here would be helpful. Cheers, Bill > > The current proposal #364 is based on minimal restrictions > based on the missing C-interoperability of LOGICAL. > I expect, that life can be more simple if we make more > restrictions, e.g., same BIND(C) roule for all routine groups > (this would mean no BIND(C) in the moment). > > Best regards > Rolf > > > ----- Original Message ----- >> From: "Bill Long" <longb(a)cray.com> >> To: mpi3-fortran(a)lists.mpi-forum.org >> Cc: rabenseifner(a)hlrs.de, "Kathryn Mohror" <kathryn(a)llnl.gov>, "Nick Maclaren" <nmm1(a)cam.ac.uk> >> Sent: Monday, March 11, 2013 2:01:37 PM >> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind >> Hi Martin, >> >> Ultimately, the problem is that some Fortran compilers (one out of >> five >> that I tried) will give an error for a dummy argument declared default >> LOGICAL in a BIND(C) interface. This is because there is not really a >> good corresponding type in C for all Fortran compilers, and the >> internal >> representation of LOGICAL in Fortran might not even match the _Bool >> type >> in C. >> >> One solution to the problem, at least for the "normal" MPI functions, >> is >> the write the Fortran wrapper in Fortran, with no BIND(C) [gets around >> the compiler error message] and within the wrapper, convert the >> LOGICAL >> value to an int value that is passed in a call to the actual C >> function >> [since the corresponding C argument is an int]. If the argument is >> intent(out) then you convert it back from int to LOGICAL after the C >> function call, before returning from the wrapper. These conversions >> are >> each single lines of Fortran code, and (if the wrapper is in a module) >> will probably get inlined, and possibly optimized away for some >> Fortran >> implementations. The goal is that C should never have to be confronted >> with the foreign Fortran default LOGICAL directly. >> >> I believe that the current wording of the MPI 3 spec for using mpif.h >> still requires dealing with the no/single/double underscore issue, and >> that is assuming one of those is the choice for default linker names >> in >> Fortran for a particular implementation. There is nothing in the >> Fortran standard that requires any of these three options. >> >> I noted that Nick Maclaren replied to this message as well. For those >> not aware, Nick is in a rather unique position of having participated >> on >> both the C and Fortran standardization committees. He pretty much >> knows where all the [Fortran-C interoperability] dead bodies are >> buried. >> >> Cheers, >> Bill >> >> >> On 3/11/13 12:18 AM, Schulz, Martin wrote: >>> Hi all, >>> >>> I am trying to catch up with the various threads on this (sorry, >>> last week was hectic and I didn't get to all emails). I have to >>> admit that I am still confused why there is a problem, but we can >>> clarify this during a phone call or during the march meeting. >>> However, doesn't not doing BINDC create a problem, since I now have >>> to again deal with the no/one/two underscore issue? This sounds like >>> a bad interface design to me, especially when we starting mixing >>> things. >>> >>> Martin >>> >>> >>> On Mar 4, 2013, at 9:47 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> >>> wrote: >>> >>>> Dear all, >>>> >>>> I forget to say thank you to all of you who helped to solve >>>> this hard problem. It was a really helpful discussion. >>>> It is a pity that we could not keep the BIND(C) for >>>> all routines in mpi_f08, which was one goal with mpi_f08 and TS >>>> 29113. >>>> >>>> In my proposal #364, we have to remove BIND(C) from >>>> - the 30 normal MPI routines with LOGICAL arguments, >>>> - the 9 MPI routines with callbacks in the argument list, >>>> - and 10 predefined callbacks, >>>> i.e., from 49 out of 357 MPI routines. >>>> >>>> I do not see a better solution that can be done by the MPI Forum. >>>> Better solutions are still possible for the 30 normal routines >>>> and/or for the 9 routines with callback-arguments as soon as >>>> the Fortran standard will include some additions and >>>> those additions are provided by the compilers - but if this >>>> will happen then it will not happen soon. >>>> >>>> It was luck that all routines with buffer arguments do not >>>> have also a LOGICAL argument. >>>> >>>> Best regards >>>> Rolf >>>> >>>> ------------------ >>>> Malcolm and all MPI implementors, >>>> and TOOLS implementors, >>>> >>>> First Malcolm, thank you for your helpful answer. >>>> After all the discussion, the MPI-3.0 errata decision is >>>> very simple: Remove BIND(C) everywhere where LOGICAL is around. >>>> >>>> I did it in the ticket #364 >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364 >>>> >>>> I hope that one of the implementors with Fortran knowledge goes >>>> through my proposal and returns an "okay" as a review on the >>>> ticket. >>>> >>>> The major changes: >>>> - BIND(C) removed on all callback abstract interfaces. >>>> - BIND(C) removed on all predefined callbacks. >>>> - Creating a new routine group "MPI_TEST" for all MPI routines >>>> with LOGICAL arguments, except MPI_OP_CREATE, which is already >>>> in an own group. >>>> - Telling that the routines in the groups MPI_TEST, >>>> MPI_OP_CREATE, MPI_REGISTER_DATEREP, and MPI_COMM_KEYVAL_CREATE >>>> cannot be implemented with BIND(C) in Fortran 2008 + TS 29113 >>>> and earlier. >>>> >>>> TOOLS implementors should be aware that I added this new routine >>>> group. >>>> >>>> Best regards >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Malcolm Cohen" <malcolm(a)nag-j.co.jp> >>>>> To: "MPI-3 Fortran working group" >>>>> <mpi3-fortran(a)lists.mpi-forum.org> >>>>> Sent: Monday, March 4, 2013 3:56:50 AM >>>>> Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran >>>>> 2008 interface - issue with the LOGICAL kind >>>>>> (B1) Is it possible, that a BIND(C) routine >>>>>> has a dummy argument that is a non-BIND(C) >>>>>> ABSTRACT INTERFACE procedure argument? >>>>> >>>>> That is not possible: all dummy arguments of a BIND(C) routine >>>>> must be >>>>> interoperable - for procedures that requires BIND(C). >>>>> >>>>> It would be reasonable to extend C_FUNLOC and C_F_PROCPOINTER to >>>>> permit >>>>> non-interoperable procedures, similarly to how we permit >>>>> non-interoperable >>>>> variables in C_LOC and C_F_POINTER. Then the argument could be >>>>> C_FUNPTR (by >>>>> value). I don't know whether this would help you though. >>>>> >>>>>> (B2) Do we have any problem with >>>>>> the TYPE(C_PTR), VALUE dummy arguments >>>>>> in the ABSTRACT INTERFACE MPI_User_function >>>>>> on MPI-3.0 page 183 line 45 - page 184 line 3 >>>>>> if the we remove the BIND(C) from this >>>>>> ABSTRACT INTERFACE (i.e. on page 183, line 47). >>>>> >>>>> No problem. >>>>> >>>>> Cheers, >>>>> -- >>>>> ................................Malcolm Cohen, Nihon NAG, Tokyo. >>>>> >>>>> _______________________________________________ >>>>> 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: Room >>>> 1.307) >>> >>> ________________________________________________________________________ >>> 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 >>> >> >> -- >> 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 > -- 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

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

14 Mar '13

Dear all, I would like to learn - Who is implementing the new mpi_f08 module -- for mpich? Is this you, Bill Long? -- for OpenMPI? Is this you, Craig? -- who else is currently implementing the new Fortran mpi_f08 module? - Do I understand correctly that both implementations: -- do use Fortran-written wrappers as MPI user-API? -- I.e., it is simple to change it to BIND(C) or non-BIND(C)? -- I.e., only for the tools people, it is of interest whether BIND(C) or non-BIND(C) was chosen? -- What are other implementations do? I ask this, to learn whether the BIND(C)/non-BIND(C) freedom for the implementations can/should be reduced to make life easier. The current proposal #364 is based on minimal restrictions based on the missing C-interoperability of LOGICAL. I expect, that life can be more simple if we make more restrictions, e.g., same BIND(C) roule for all routine groups (this would mean no BIND(C) in the moment). Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: mpi3-fortran(a)lists.mpi-forum.org > Cc: rabenseifner(a)hlrs.de, "Kathryn Mohror" <kathryn(a)llnl.gov>, "Nick Maclaren" <nmm1(a)cam.ac.uk> > Sent: Monday, March 11, 2013 2:01:37 PM > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind > Hi Martin, > > Ultimately, the problem is that some Fortran compilers (one out of > five > that I tried) will give an error for a dummy argument declared default > LOGICAL in a BIND(C) interface. This is because there is not really a > good corresponding type in C for all Fortran compilers, and the > internal > representation of LOGICAL in Fortran might not even match the _Bool > type > in C. > > One solution to the problem, at least for the "normal" MPI functions, > is > the write the Fortran wrapper in Fortran, with no BIND(C) [gets around > the compiler error message] and within the wrapper, convert the > LOGICAL > value to an int value that is passed in a call to the actual C > function > [since the corresponding C argument is an int]. If the argument is > intent(out) then you convert it back from int to LOGICAL after the C > function call, before returning from the wrapper. These conversions > are > each single lines of Fortran code, and (if the wrapper is in a module) > will probably get inlined, and possibly optimized away for some > Fortran > implementations. The goal is that C should never have to be confronted > with the foreign Fortran default LOGICAL directly. > > I believe that the current wording of the MPI 3 spec for using mpif.h > still requires dealing with the no/single/double underscore issue, and > that is assuming one of those is the choice for default linker names > in > Fortran for a particular implementation. There is nothing in the > Fortran standard that requires any of these three options. > > I noted that Nick Maclaren replied to this message as well. For those > not aware, Nick is in a rather unique position of having participated > on > both the C and Fortran standardization committees. He pretty much > knows where all the [Fortran-C interoperability] dead bodies are > buried. > > Cheers, > Bill > > > On 3/11/13 12:18 AM, Schulz, Martin wrote: > > Hi all, > > > > I am trying to catch up with the various threads on this (sorry, > > last week was hectic and I didn't get to all emails). I have to > > admit that I am still confused why there is a problem, but we can > > clarify this during a phone call or during the march meeting. > > However, doesn't not doing BINDC create a problem, since I now have > > to again deal with the no/one/two underscore issue? This sounds like > > a bad interface design to me, especially when we starting mixing > > things. > > > > Martin > > > > > > On Mar 4, 2013, at 9:47 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > > wrote: > > > >> Dear all, > >> > >> I forget to say thank you to all of you who helped to solve > >> this hard problem. It was a really helpful discussion. > >> It is a pity that we could not keep the BIND(C) for > >> all routines in mpi_f08, which was one goal with mpi_f08 and TS > >> 29113. > >> > >> In my proposal #364, we have to remove BIND(C) from > >> - the 30 normal MPI routines with LOGICAL arguments, > >> - the 9 MPI routines with callbacks in the argument list, > >> - and 10 predefined callbacks, > >> i.e., from 49 out of 357 MPI routines. > >> > >> I do not see a better solution that can be done by the MPI Forum. > >> Better solutions are still possible for the 30 normal routines > >> and/or for the 9 routines with callback-arguments as soon as > >> the Fortran standard will include some additions and > >> those additions are provided by the compilers - but if this > >> will happen then it will not happen soon. > >> > >> It was luck that all routines with buffer arguments do not > >> have also a LOGICAL argument. > >> > >> Best regards > >> Rolf > >> > >> ------------------ > >> Malcolm and all MPI implementors, > >> and TOOLS implementors, > >> > >> First Malcolm, thank you for your helpful answer. > >> After all the discussion, the MPI-3.0 errata decision is > >> very simple: Remove BIND(C) everywhere where LOGICAL is around. > >> > >> I did it in the ticket #364 > >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364 > >> > >> I hope that one of the implementors with Fortran knowledge goes > >> through my proposal and returns an "okay" as a review on the > >> ticket. > >> > >> The major changes: > >> - BIND(C) removed on all callback abstract interfaces. > >> - BIND(C) removed on all predefined callbacks. > >> - Creating a new routine group "MPI_TEST" for all MPI routines > >> with LOGICAL arguments, except MPI_OP_CREATE, which is already > >> in an own group. > >> - Telling that the routines in the groups MPI_TEST, > >> MPI_OP_CREATE, MPI_REGISTER_DATEREP, and MPI_COMM_KEYVAL_CREATE > >> cannot be implemented with BIND(C) in Fortran 2008 + TS 29113 > >> and earlier. > >> > >> TOOLS implementors should be aware that I added this new routine > >> group. > >> > >> Best regards > >> Rolf > >> > >> ----- Original Message ----- > >>> From: "Malcolm Cohen" <malcolm(a)nag-j.co.jp> > >>> To: "MPI-3 Fortran working group" > >>> <mpi3-fortran(a)lists.mpi-forum.org> > >>> Sent: Monday, March 4, 2013 3:56:50 AM > >>> Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran > >>> 2008 interface - issue with the LOGICAL kind > >>>> (B1) Is it possible, that a BIND(C) routine > >>>> has a dummy argument that is a non-BIND(C) > >>>> ABSTRACT INTERFACE procedure argument? > >>> > >>> That is not possible: all dummy arguments of a BIND(C) routine > >>> must be > >>> interoperable - for procedures that requires BIND(C). > >>> > >>> It would be reasonable to extend C_FUNLOC and C_F_PROCPOINTER to > >>> permit > >>> non-interoperable procedures, similarly to how we permit > >>> non-interoperable > >>> variables in C_LOC and C_F_POINTER. Then the argument could be > >>> C_FUNPTR (by > >>> value). I don't know whether this would help you though. > >>> > >>>> (B2) Do we have any problem with > >>>> the TYPE(C_PTR), VALUE dummy arguments > >>>> in the ABSTRACT INTERFACE MPI_User_function > >>>> on MPI-3.0 page 183 line 45 - page 184 line 3 > >>>> if the we remove the BIND(C) from this > >>>> ABSTRACT INTERFACE (i.e. on page 183, line 47). > >>> > >>> No problem. > >>> > >>> Cheers, > >>> -- > >>> ................................Malcolm Cohen, Nihon NAG, Tokyo. > >>> > >>> _______________________________________________ > >>> 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: Room > >> 1.307) > > > > ________________________________________________________________________ > > 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 > > > > -- > 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)

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 11 Mar '13

11 Mar '13

On Mar 11 2013, Bill Long wrote: > >I noted that Nick Maclaren replied to this message as well. For those >not aware, Nick is in a rather unique position of having participated on >both the C and Fortran standardization committees. He pretty much >knows where all the [Fortran-C interoperability] dead bodies are buried. Not really :-( I keep learning about new ones, as well as ones that I had thought had been decently resolved not having been. But I do know far more than is good for my sanity! Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 11 Mar '13

11 Mar '13

Hi Martin, Ultimately, the problem is that some Fortran compilers (one out of five that I tried) will give an error for a dummy argument declared default LOGICAL in a BIND(C) interface. This is because there is not really a good corresponding type in C for all Fortran compilers, and the internal representation of LOGICAL in Fortran might not even match the _Bool type in C. One solution to the problem, at least for the "normal" MPI functions, is the write the Fortran wrapper in Fortran, with no BIND(C) [gets around the compiler error message] and within the wrapper, convert the LOGICAL value to an int value that is passed in a call to the actual C function [since the corresponding C argument is an int]. If the argument is intent(out) then you convert it back from int to LOGICAL after the C function call, before returning from the wrapper. These conversions are each single lines of Fortran code, and (if the wrapper is in a module) will probably get inlined, and possibly optimized away for some Fortran implementations. The goal is that C should never have to be confronted with the foreign Fortran default LOGICAL directly. I believe that the current wording of the MPI 3 spec for using mpif.h still requires dealing with the no/single/double underscore issue, and that is assuming one of those is the choice for default linker names in Fortran for a particular implementation. There is nothing in the Fortran standard that requires any of these three options. I noted that Nick Maclaren replied to this message as well. For those not aware, Nick is in a rather unique position of having participated on both the C and Fortran standardization committees. He pretty much knows where all the [Fortran-C interoperability] dead bodies are buried. Cheers, Bill On 3/11/13 12:18 AM, Schulz, Martin wrote: > Hi all, > > I am trying to catch up with the various threads on this (sorry, last week was hectic and I didn't get to all emails). I have to admit that I am still confused why there is a problem, but we can clarify this during a phone call or during the march meeting. However, doesn't not doing BINDC create a problem, since I now have to again deal with the no/one/two underscore issue? This sounds like a bad interface design to me, especially when we starting mixing things. > > Martin > > > On Mar 4, 2013, at 9:47 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > >> Dear all, >> >> I forget to say thank you to all of you who helped to solve >> this hard problem. It was a really helpful discussion. >> It is a pity that we could not keep the BIND(C) for >> all routines in mpi_f08, which was one goal with mpi_f08 and TS 29113. >> >> In my proposal #364, we have to remove BIND(C) from >> - the 30 normal MPI routines with LOGICAL arguments, >> - the 9 MPI routines with callbacks in the argument list, >> - and 10 predefined callbacks, >> i.e., from 49 out of 357 MPI routines. >> >> I do not see a better solution that can be done by the MPI Forum. >> Better solutions are still possible for the 30 normal routines >> and/or for the 9 routines with callback-arguments as soon as >> the Fortran standard will include some additions and >> those additions are provided by the compilers - but if this >> will happen then it will not happen soon. >> >> It was luck that all routines with buffer arguments do not >> have also a LOGICAL argument. >> >> Best regards >> Rolf >> >> ------------------ >> Malcolm and all MPI implementors, >> and TOOLS implementors, >> >> First Malcolm, thank you for your helpful answer. >> After all the discussion, the MPI-3.0 errata decision is >> very simple: Remove BIND(C) everywhere where LOGICAL is around. >> >> I did it in the ticket #364 >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364 >> >> I hope that one of the implementors with Fortran knowledge goes >> through my proposal and returns an "okay" as a review on the ticket. >> >> The major changes: >> - BIND(C) removed on all callback abstract interfaces. >> - BIND(C) removed on all predefined callbacks. >> - Creating a new routine group "MPI_TEST" for all MPI routines >> with LOGICAL arguments, except MPI_OP_CREATE, which is already >> in an own group. >> - Telling that the routines in the groups MPI_TEST, >> MPI_OP_CREATE, MPI_REGISTER_DATEREP, and MPI_COMM_KEYVAL_CREATE >> cannot be implemented with BIND(C) in Fortran 2008 + TS 29113 and earlier. >> >> TOOLS implementors should be aware that I added this new routine group. >> >> Best regards >> Rolf >> >> ----- Original Message ----- >>> From: "Malcolm Cohen" <malcolm(a)nag-j.co.jp> >>> To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> >>> Sent: Monday, March 4, 2013 3:56:50 AM >>> Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind >>>> (B1) Is it possible, that a BIND(C) routine >>>> has a dummy argument that is a non-BIND(C) >>>> ABSTRACT INTERFACE procedure argument? >>> >>> That is not possible: all dummy arguments of a BIND(C) routine must be >>> interoperable - for procedures that requires BIND(C). >>> >>> It would be reasonable to extend C_FUNLOC and C_F_PROCPOINTER to >>> permit >>> non-interoperable procedures, similarly to how we permit >>> non-interoperable >>> variables in C_LOC and C_F_POINTER. Then the argument could be >>> C_FUNPTR (by >>> value). I don't know whether this would help you though. >>> >>>> (B2) Do we have any problem with >>>> the TYPE(C_PTR), VALUE dummy arguments >>>> in the ABSTRACT INTERFACE MPI_User_function >>>> on MPI-3.0 page 183 line 45 - page 184 line 3 >>>> if the we remove the BIND(C) from this >>>> ABSTRACT INTERFACE (i.e. on page 183, line 47). >>> >>> No problem. >>> >>> Cheers, >>> -- >>> ................................Malcolm Cohen, Nihon NAG, Tokyo. >>> >>> _______________________________________________ >>> 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: Room 1.307) > > ________________________________________________________________________ > 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 > -- 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

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 11 Mar '13

11 Mar '13

On Mar 11 2013, Schulz, Martin wrote: > > I am trying to catch up with the various threads on this (sorry, last > week was hectic and I didn't get to all emails). I have to admit that I > am still confused why there is a problem, but we can clarify this during > a phone call or during the march meeting. However, doesn't not doing > BINDC create a problem, since I now have to again deal with the > no/one/two underscore issue? This sounds like a bad interface design to > me, especially when we starting mixing things. You are speaking as an implementor, right? The user does not have to worry about that, with or without BIND(C). There are actually much nastier implementation problems with mixing Fortran and C, in general, so I don't see that it's a big deal. The exception is if you use a user-defined reduction operator into a mixture of Fortran and C, when getting it to work at all is such an evil issue that you need all the help you can get! Actually, that's just a variation of the heterogeneous node problem, which is somewhat swept under the carpet by MPI and affects very, very few users. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Schulz, Martin 11 Mar '13

11 Mar '13

Hi all, I am trying to catch up with the various threads on this (sorry, last week was hectic and I didn't get to all emails). I have to admit that I am still confused why there is a problem, but we can clarify this during a phone call or during the march meeting. However, doesn't not doing BINDC create a problem, since I now have to again deal with the no/one/two underscore issue? This sounds like a bad interface design to me, especially when we starting mixing things. Martin On Mar 4, 2013, at 9:47 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Dear all, > > I forget to say thank you to all of you who helped to solve > this hard problem. It was a really helpful discussion. > It is a pity that we could not keep the BIND(C) for > all routines in mpi_f08, which was one goal with mpi_f08 and TS 29113. > > In my proposal #364, we have to remove BIND(C) from > - the 30 normal MPI routines with LOGICAL arguments, > - the 9 MPI routines with callbacks in the argument list, > - and 10 predefined callbacks, > i.e., from 49 out of 357 MPI routines. > > I do not see a better solution that can be done by the MPI Forum. > Better solutions are still possible for the 30 normal routines > and/or for the 9 routines with callback-arguments as soon as > the Fortran standard will include some additions and > those additions are provided by the compilers - but if this > will happen then it will not happen soon. > > It was luck that all routines with buffer arguments do not > have also a LOGICAL argument. > > Best regards > Rolf > > ------------------ > Malcolm and all MPI implementors, > and TOOLS implementors, > > First Malcolm, thank you for your helpful answer. > After all the discussion, the MPI-3.0 errata decision is > very simple: Remove BIND(C) everywhere where LOGICAL is around. > > I did it in the ticket #364 > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364 > > I hope that one of the implementors with Fortran knowledge goes > through my proposal and returns an "okay" as a review on the ticket. > > The major changes: > - BIND(C) removed on all callback abstract interfaces. > - BIND(C) removed on all predefined callbacks. > - Creating a new routine group "MPI_TEST" for all MPI routines > with LOGICAL arguments, except MPI_OP_CREATE, which is already > in an own group. > - Telling that the routines in the groups MPI_TEST, > MPI_OP_CREATE, MPI_REGISTER_DATEREP, and MPI_COMM_KEYVAL_CREATE > cannot be implemented with BIND(C) in Fortran 2008 + TS 29113 and earlier. > > TOOLS implementors should be aware that I added this new routine group. > > Best regards > Rolf > > ----- Original Message ----- >> From: "Malcolm Cohen" <malcolm(a)nag-j.co.jp> >> To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> >> Sent: Monday, March 4, 2013 3:56:50 AM >> Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind >>> (B1) Is it possible, that a BIND(C) routine >>> has a dummy argument that is a non-BIND(C) >>> ABSTRACT INTERFACE procedure argument? >> >> That is not possible: all dummy arguments of a BIND(C) routine must be >> interoperable - for procedures that requires BIND(C). >> >> It would be reasonable to extend C_FUNLOC and C_F_PROCPOINTER to >> permit >> non-interoperable procedures, similarly to how we permit >> non-interoperable >> variables in C_LOC and C_F_POINTER. Then the argument could be >> C_FUNPTR (by >> value). I don't know whether this would help you though. >> >>> (B2) Do we have any problem with >>> the TYPE(C_PTR), VALUE dummy arguments >>> in the ABSTRACT INTERFACE MPI_User_function >>> on MPI-3.0 page 183 line 45 - page 184 line 3 >>> if the we remove the BIND(C) from this >>> ABSTRACT INTERFACE (i.e. on page 183, line 47). >> >> No problem. >> >> Cheers, >> -- >> ................................Malcolm Cohen, Nihon NAG, Tokyo. >> >> _______________________________________________ >> 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: Room 1.307) ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

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

07 Mar '13

Dear all Fortran group members and MPI implementers, Is the solution in ticket #364 now also okay for you? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364 Key points have been: - All routines with LOGICAL dummy arguments are put into an additional routine group. Those routines cannot be implemented with BIND(C) if the compiler is Fortran standard compliant. This does not have any implications for the MPI users, except for callback routines. - The proposed solution does not require special C based bool datatypes for the normal MPI Fortran programmer when using the mpi_f08 module and typical routines with logical flags like MPI_Test. - The abstract interfaces for the callbacks are switched from BIND(C) to non-BIND(C). This is the "hard" change in this MPI-3.0 erratum. The current definition of the callbacks in mpi_f08 module was not Fortran compliant. This was detected not earlier. It is resolved with this ticket. Implication is that also routines with callbacks as dummy arguments (e.g. MPI_OP_CREATE) cannot be implemented with BIND(C). The proposal is based on minimal surprise for the MPI users. Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, March 5, 2013 5:20:53 PM > Subject: Re: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind > I see. So, we are OK as long as there is no routine that has both a > choice buffer argument and a LOGICAL argument. > > Cheers, > Bill > > > On 3/5/13 10:07 AM, Rolf Rabenseifner wrote: > > Bill, > > > >> So, you are saying that MPI_SUBARRAYS_SUPPORTED = .true. is not > >> allowed (page 605 lines 23-30)? > > > > No, it is allowed. > > > > The important text is p606:45 - p607:3. > > This is the basis for the "Upgrade" columns in table p609:18-32. > > These upgrades have MPI_SUBARRAYS_SUPPORTED==.TRUE. > > although most routine groups are still without BIND(C). > > > > Therefore, it is no problem to have no BIND(C) for > > the new MPI_TEST routine group. > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "Bill Long" <longb(a)cray.com> > >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > >> Cc: "MPI-3 Fortran working group" > >> <mpi3-fortran(a)lists.mpi-forum.org> > >> Sent: Monday, March 4, 2013 5:44:04 PM > >> Subject: Re: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI > >> 3.0:Fortran 2008 interface - issue with the LOGICAL kind > >> On 3/4/13 10:34 AM, Rolf Rabenseifner wrote: > >>> Bill, > >>> > >>> Without BIND(C), you have to make it according to > >>> MPI-3.0 page 605, lines 31-38. > >> > >> So, you are saying that MPI_SUBARRAYS_SUPPORTED = .true. is not > >> allowed > >> (page 605 lines 23-30)? > >> > >> This still does not solve the problem of the wrapper names being > >> inaccessible when only the mpif.h include file is used. Unless, of > >> course, the include file consists only of "use mpi", but this is > >> problematic because of statement ordering rules. > >> > >> Cheers, > >> Bill > >> > >>> > >>> Therefore, ticket #364 should work. > >>> > >>> Please check again. > >>> > >>> Best regards > >>> Rolf > > > > -- > 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 > > > _______________________________________________ > 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: Room 1.307)

1 0

Re: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 05 Mar '13

05 Mar '13

I see. So, we are OK as long as there is no routine that has both a choice buffer argument and a LOGICAL argument. Cheers, Bill On 3/5/13 10:07 AM, Rolf Rabenseifner wrote: > Bill, > >> So, you are saying that MPI_SUBARRAYS_SUPPORTED = .true. is not >> allowed (page 605 lines 23-30)? > > No, it is allowed. > > The important text is p606:45 - p607:3. > This is the basis for the "Upgrade" columns in table p609:18-32. > These upgrades have MPI_SUBARRAYS_SUPPORTED==.TRUE. > although most routine groups are still without BIND(C). > > Therefore, it is no problem to have no BIND(C) for > the new MPI_TEST routine group. > > Best regards > Rolf > > ----- Original Message ----- >> From: "Bill Long" <longb(a)cray.com> >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> Cc: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> >> Sent: Monday, March 4, 2013 5:44:04 PM >> Subject: Re: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind >> On 3/4/13 10:34 AM, Rolf Rabenseifner wrote: >>> Bill, >>> >>> Without BIND(C), you have to make it according to >>> MPI-3.0 page 605, lines 31-38. >> >> So, you are saying that MPI_SUBARRAYS_SUPPORTED = .true. is not >> allowed >> (page 605 lines 23-30)? >> >> This still does not solve the problem of the wrapper names being >> inaccessible when only the mpif.h include file is used. Unless, of >> course, the include file consists only of "use mpi", but this is >> problematic because of statement ordering rules. >> >> Cheers, >> Bill >> >>> >>> Therefore, ticket #364 should work. >>> >>> Please check again. >>> >>> Best regards >>> Rolf > -- 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

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

05 Mar '13

I fully agree with Jeff. We have to clearly distinguish: - (A) LOGICAL in normal MPI routines (e.g. MPI_Test) - (B) LOGICAL in callbacks, and here - (B1) the callback routines written by users based on the ABSTRACT INTERFACEs, - (B2) the predefined callback routines in the MPI lib, - (B3) The MPI routines with callback PROCEDURE dummy arguments. For (A), it would be an absolute no-go to change the application's actual arguments, which may be an array of LOGICALs. We did this for the handles and that should be enough of surprise. We should first discuss (A) before we try to solve (B). For (B), the minumum change should be done for the MPI-1 interface, i.e., for MPI_OP_CREATE. The proposal in #364 is mainly driven by the goal, that the user do not see further changes for (A). Additionally no surprises if the user uses (B3) in combination with (B2). Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Cc: "Martin Schulz" <schulzm(a)llnl.gov> > Sent: Tuesday, March 5, 2013 3:09:27 PM > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > The problems I have with changing to any flavor of INTEGER are > twofold: > > 1. Backwards incompatibility. Yes, mpi_f08 is new, but there's now > nonzero number of codes out there that use it, and are therefore using > default LOGICAL. > > 2. Violates the Law of Least Astonishment. For 15+ years, Fortran devs > have been using default LOGICAL for MPI's boolean flags, and testing > with .true. and .false.. Changing that to INTEGER (any flavor) would > be downright weird. > > > On Mar 4, 2013, at 7:57 PM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> > wrote: > > > I talked with Bill briefly on the phone and he suggested something > > close to what we already do, namely use overloading to get around > > the problem (see Bill's earlier comment on two levels of wrappers). > > > > We could switch to LOGICAL(C_BOOL) dummy arguments in all procedures > > with BIND(C) interfaces. Then in addition we could overload these > > functions (like MPI_Test) with thin wrappers that are required to > > call the regular BIND(C) version so that the tools folks are happy. > > Regular users would never know the difference. I suppose we could > > actually use INTEGER(C_INT) in these interfaces rather than > > LOGICAL(C_BOOL) as there is less chance of confusion and > > INTEGER(C_INT) and LOGICAL can always different. Whereas > > LOGICAL(C_BOOL) and LOGICAL may be the same type. > > > > Bill also suggested that replacing LOGICAL dummy arguments with > > INTEGER(C_INT) in the callback routines would a safer way to go. > > > > Craig Rasmussen > > CAS Scientific Programmer > > rasmus(a)cas.uoregon.edu > > > > > > > > > > On Mar 4, 2013, at 12:19 PM, Bill Long wrote: > > > >> > >> > >> On 3/4/13 1:26 PM, Tobias Burnus wrote: > >>> Bill Long wrote: > >>>>> > >>>>> There isn't any difficulty about a Fortran wrapper using > >>>>> integers (as > >>>>> C does), and converting them to LOGICAL, but it can't be > >>>>> BIND(C). > >>>> > >>>> There is also no difficulty in having the wrapper arguments being > >>>> LOGICAL. > >>>> > >>>> subroutine sub (x) bind(c, name="MPI_xxx_f") > >>>> logical :: x > >>>> integer(int) :: cx > >>>> > >>>> cx = merge(1, 0, x) > >>> > >>> Well, except that compilers might simply reject a default-kind > >>> LOGICAL > >>> with BIND(C), in line with the Fortran standard. > >> > >> Ug. I tried 5 compilers. Three (Cray, Intel, PGI) just let it pass. > >> One gave an error, and one gave a warning. What a mess. I'm more > >> convinced now that before that the only practical solution here is > >> to get rid of the LOGICAL arguments, replacing them with INTEGER > >> arguments, which is what the C functions expect anyway. > >> (Alternatively, the problem goes away if support for mpif.h is > >> removed, which I would highly recommend anyway.) > >> > >> I'm trying to work out how to use two layers of wrapper functions > >> to get around the error from that one compiler. Unattractive, to > >> say the least. > >> > >> Cheers, > >> Bill > >> > >> > >>> > >>> Your code above assumes that a Fortran compiler allows passing a > >>> default-kind LOGICAL to a Bind(C) procedure and that it then can > >>> handle > >>> that LOGICAL. I think no one really doubts the second part. But > >>> the > >>> first part is not really covered by the Fortran standard and > >>> standard-conforming compilers do exist, which reject default-kind > >>> LOGICALs. > >>> > >>> J3/WG5 could change the standard such that it supports other > >>> LOGICAL > >>> kinds besides C_Bool, including kind(.true.). However, if > >>> LOGICAL(kind=kind(.true.) / C_INT) exists, users will assume that > >>> it > >>> acts like C's "int", which will lead to problems. So far, I > >>> haven't seen > >>> a convincing proposal how to solve this. > >>> > >>> Tobias > >>> _______________________________________________ > >>> 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 > >> > >> > >> _______________________________________________ > >> mpi3-fortran mailing list > >> mpi3-fortran(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > > _______________________________________________ > > 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/ > > > _______________________________________________ > 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: Room 1.307)

1 0

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

05 Mar '13

Bill, > So, you are saying that MPI_SUBARRAYS_SUPPORTED = .true. is not > allowed (page 605 lines 23-30)? No, it is allowed. The important text is p606:45 - p607:3. This is the basis for the "Upgrade" columns in table p609:18-32. These upgrades have MPI_SUBARRAYS_SUPPORTED==.TRUE. although most routine groups are still without BIND(C). Therefore, it is no problem to have no BIND(C) for the new MPI_TEST routine group. Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Monday, March 4, 2013 5:44:04 PM > Subject: Re: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind > On 3/4/13 10:34 AM, Rolf Rabenseifner wrote: > > Bill, > > > > Without BIND(C), you have to make it according to > > MPI-3.0 page 605, lines 31-38. > > So, you are saying that MPI_SUBARRAYS_SUPPORTED = .true. is not > allowed > (page 605 lines 23-30)? > > This still does not solve the problem of the wrapper names being > inaccessible when only the mpif.h include file is used. Unless, of > course, the include file consists only of "use mpi", but this is > problematic because of statement ordering rules. > > Cheers, > Bill > > > > > Therefore, ticket #364 should work. > > > > Please check again. > > > > Best regards > > 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: Room 1.307)

1 0