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 N.M. Maclaren 16 Mar '13

16 Mar '13

On Mar 16 2013, Craig Rasmussen wrote: > >> -- I.e., it is simple to change it to BIND(C) or non-BIND(C)? > > We use macro magic to turn BIND(C) on and off so it is not hard for us to > change. As any competent implementor would! Changing is the easy bit; ensuring that things don't break is the issue. > Rolf, is an implementation compliant if Fortran wrappers are used in a > module to call C directly so that the tools community can't intercept the > call in Fortran? Does this break any current tools implementations? I > assume it does as I believe the MPI standard requires that a Fortran MPI > user be able to intercept the MPI call in Fortran and then call MPI. It does. But, once the call has reached the PMPI procedures, it's all black magic from then on, so that they can certainly call C directly, or 370 Assembler, BLISS, Lisp or anything else! That would probably be incompatible with a few tools, of course :-) > I would like to argue for a solution that would allow BIND(C) to be used > within 10 years to remove ALL requirements for the tools community to > handle the underscore problem. That is a poor way to phrase it, but I know what you mean. We put some extensions into the TS to allow that, and I am going to propose a few more for the next Fortran standard. However, two VERY serious problems remain: 1) There are certain features that are semantically incompatible, and it will be VERY hard to allow those in a BIND(C) interface. I did suggest LOGICAL(C_INT_AS_BOOL) as a possibility and got a right earful :-) As I rather agreed with the objections, I shall not pursue the matter. 2) WG14. C11 did not create the chaos that C99 did, but is quite seriously different in some important ways. Plans are under way for C14, and the majority of C communities have chosen their own C dialect, usually based on some combination of C90 and C99. The one certainty is that the C language is chaos in motion, and it's not going to get better. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 15 Mar '13

15 Mar '13

On Mar 14, 2013, at 2: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? > -- for OpenMPI? > Is this you, Craig? Jeff and I have done the Open MPI implementation. > -- 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? We use thin Fortran wrappers that call the original Open MPI Fortran wrappers (mpif.h). For performance reasons we will switch to thin Fortran wrappers calling the C implementation directly for some routines latter. > -- I.e., it is simple to change it to BIND(C) or non-BIND(C)? We use macro magic to turn BIND(C) on and off so it is not hard for us to change. > -- I.e., only for the tools people, it is of > interest whether BIND(C) or non-BIND(C) was chosen? BIND(C) provides a well known name for the tools people to implement and removes the underscore compiler dependent issue. Rolf, is an implementation compliant if Fortran wrappers are used in a module to call C directly so that the tools community can't intercept the call in Fortran? Does this break any current tools implementations? I assume it does as I believe the MPI standard requires that a Fortran MPI user be able to intercept the MPI call in Fortran and then call MPI. > -- 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). I would like to argue for a solution that would allow BIND(C) to be used within 10 years to remove ALL requirements for the tools community to handle the underscore problem. -craig

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 15 Mar '13

15 Mar '13

On Mar 15, 2013, at 3:30 PM, Bill Long wrote: > Hi Craig, > > There were many follow-up messages in this thread.... > > On 3/15/13 12:16 PM, Craig Rasmussen wrote: >> On Mar 10, 2013, at 10:18 PM, 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. >> >> Yes, I believe that removing BIND(C) entirely makes it virtually impossible for the tools community. Not only is there the underscore issue but some implementors want to put the code in modules which makes name mangling MUCH worse. >> > > I would prefer that the tools people ignore the Fortran wrappers completely and instead only target the underlying C functions in the MPI library. If a library function is entirely replaced by a Fortran routine, then that routine requires a BIND(C) specifying the C name. Otherwise, BIND(C) would not be needed for the wrappers. This scheme seems to circumvent all of the recent problems, and also make life much simpler for the tools people who only need to look at the C functions. It also avoids the problem of aggressively optimizing compilers inlining and eliminating the wrappers (which would then be unavailable for the tools). I would think that forcing users to throttle back compiler optimization just to get the tools to work would be counterproductive. > We had several discussions about this a year or so ago. I agreed with you. But for reasons I don't fully understand, this wasn't deemed sufficient. A couple of issues that need to be considered are: 1. A vendor is allowed to implement the standard purely in Fortran. There is at least one major compiler vendor that implements a portion of the MPI routines in Fortran for performance. 2. Martin has stated that the tools community wants control at the earliest opportunity. Thus they want control at the wrapper level. I really don't understand this but so it is. -craig

1 0

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

15 Mar '13

Hi Craig, There were many follow-up messages in this thread.... On 3/15/13 12:16 PM, Craig Rasmussen wrote: > On Mar 10, 2013, at 10:18 PM, 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. > > Yes, I believe that removing BIND(C) entirely makes it virtually impossible for the tools community. Not only is there the underscore issue but some implementors want to put the code in modules which makes name mangling MUCH worse. > I would prefer that the tools people ignore the Fortran wrappers completely and instead only target the underlying C functions in the MPI library. If a library function is entirely replaced by a Fortran routine, then that routine requires a BIND(C) specifying the C name. Otherwise, BIND(C) would not be needed for the wrappers. This scheme seems to circumvent all of the recent problems, and also make life much simpler for the tools people who only need to look at the C functions. It also avoids the problem of aggressively optimizing compilers inlining and eliminating the wrappers (which would then be unavailable for the tools). I would think that forcing users to throttle back compiler optimization just to get the tools to work would be counterproductive. Cheers, Bill > I think the best solution is to add on to Rolf's proposal for problem A. The addition is that there must also be a BIND(C) interface for the tools community that replaces default LOGICAL with INTEGER(C_INT). > > The overloaded version (INTEGER(C_INT)) will be called by implementor so that it can be intercepted by PMPI users. > > Martin, do you see a problem with this? It adds an additional wrapper call, one that you don't see. If you like we could have a phone conversation today between you and I. Then perhaps a group conference call the week of March 25. > > -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

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

15 Mar '13

On 3/15/13 1:19 PM, Hubert Ritzdorf wrote: > Hi, > > I'm still developing MPI and I'm also implementing the mpi_f08 module. > My concern in connection with BIND(C) are the routines which use > character strings (for example MPI_Error_string()).. > My Intel compiler aborts the compilation for these functions with > > A character dummy argument with length other than 1 is not interoperable Right. gfortran does the same. In the interface at 349:14-19, the BIND(C) is not compatible with specifying a LEN for the character argument greater than 1. I am not using BIND(C) in the Fortran wrapper definitions. I'm using 349:14-19 as printed except with the BIND(C) deleted. In the corresponding interface block for the actual C function in the library, the declaration is a character(1) array string(*). Here are the texts: Interface for C function (from 349:13) interface !--> MPI_Error_string ! int MPI_Error_string (int errorcode, char *string, int *resultlen); function MPI_Error_string_C (errorcode, string, resultlen) & BIND(C, name="MPI_Error_string") RESULT (res) import :: c_int, c_char integer(c_int),value,intent(in) :: errorcode character(kind=c_char),intent(out) :: string(*) integer(c_int),intent(out) :: resultlen integer(c_int) :: res end function MPI_Error_string_C end interface Fortran wrapper: !--> MPI_Error_string subroutine MPI_Error_string (errorcode, string, resultlen, ierror) use :: mpi_C_interfaces_nobuf, only: c_char, MPI_Error_string_C INTEGER, INTENT(IN) :: errorcode CHARACTER(LEN=MPI_MAX_ERROR_STRING), INTENT(OUT) :: string INTEGER, INTENT(OUT) :: resultlen INTEGER, OPTIONAL, INTENT(OUT) :: ierror integer(c_int) :: errorcode_c integer(c_int) :: resultlen_C integer(c_int) :: res errorcode_c = errorcode res = MPI_Error_string_C (errorcode_c, string, resultlen_c) resultlen = resultlen_c if (present(ierror)) ierror = res end subroutine MPI_Error_string This seems to work - at least it compiles with no errors with 2 different compilers. > > I think, that this is correct (but I possibly missed some info on future changes in TSxxxxx). > (Nick mentioned in a previous e-mail: > "(C) Default CHARACTER is supported only if KIND(' ') is equal to > C_CHAR. However, that will almost certainly be the case." > I don't know whether this statement fits to the error message above. > But almost was true also for the LOGICAL case). > Or is this another class of routines which don't support BIND(C) ? > > What's about future developments in C and Fortran ? The Fortran committee operates under the assumption that it cannot require (or even influence) changes in the C standard. The list of C types for which interoperability is supported is fairly limited. There is an assumption that the C standard will not change the meanings of these types, but if they do, and Fortran chooses to be compatible with that new C standard, then the changes would be in Fortran. Fortran 2008 specifies C99 as the C standard for purposes of the interoperability feature. For the TS, everything that is not native to C (the include file and specified functions) all have to be supplied by the Fortran vendor. Cheers, Bill > May they generate new problems for BIND(C) > or less problems (i.e. is there a coordinated standardization effort between Fortran and C > in order to reduce the interoperability problems) ? > > Hubert > -- 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 15 Mar '13

15 Mar '13

On Mar 15 2013, Tobias Burnus wrote: > >Do you suggest to add BIND(C++extern-C) to Fortran? That is >compatibility with C++'s 'extern "C" {'? No - I was referring to the serious incompatibilities between C++ and C, and between C++03 and C++11, that have been caused by C99, C11 and their interpretations. Just you wait for C14 :-( Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Tobias Burnus 15 Mar '13

15 Mar '13

Am 15.03.2013 19:45, schrieb N.M. Maclaren: > On Mar 15 2013, Hubert Ritzdorf wrote: >> >> I'm still developing MPI and I'm also implementing the mpi_f08 module. >> My concern in connection with BIND(C) are the routines which use >> character strings (for example MPI_Error_string()).. My Intel >> compiler aborts the compilation for these functions with >> >> A character dummy argument with length other than 1 is not interoperable > Ugh. That needs looking into. They can be mapped to lengths of 1 > using sequence association, of course. My understanding is: a) Fortran 2003 allows character(len=1,kind=c_char) with Bind(C), which interoperates with "char *". (And sequence association can be used.) b) Fortran 2008 allows character(len=<const-expr>) c) TS 29113 also allows character(len=*) and character(len=:) - however, in that case, the TS 29113 array descriptor is used - instead of passing the data directly. To (a): See 15.2.1. To (b): See 15.3.5. To (c): See TS 29113, 8.7 (6)(b) and the paragraph after (6)(d). Thus, Intel's error message is in line with Fortran 2003. However, MPI_F08 requires Fortran 2008 plus TS 29113. In case of MPI_ERROR_STRING, the F2008+TS29113 interface uses CHARACTER(LEN=MPI_MAX_ERROR_STRING), hence, Fortran 2008's support is sufficient and no TS 29113 feature is required. >> What's about future developments in C and Fortran ? May they generate >> new problems for BIND(C) or less problems (i.e. is there a >> coordinated standardization effort between Fortran and C in order to >> reduce the interoperability problems) ? > > They have already generated massive new problems for interoperability, > not merely between Fortran and C, but between C++ and C. Do you suggest to add BIND(C++extern-C) to Fortran? That is compatibility with C++'s 'extern "C" {'? Tobias

1 0

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

15 Mar '13

On Mar 15 2013, Hubert Ritzdorf wrote: > >I'm still developing MPI and I'm also implementing the mpi_f08 module. >My concern in connection with BIND(C) are the routines which use >character strings (for example MPI_Error_string()).. >My Intel compiler aborts the compilation for these functions with > >A character dummy argument with length other than 1 is not interoperable Ugh. That needs looking into. They can be mapped to lengths of 1 using sequence association, of course. > What's about future developments in C and Fortran ? May they generate new > problems for BIND(C) or less problems (i.e. is there a coordinated > standardization effort between Fortran and C in order to reduce the > interoperability problems) ? < Comments omitted because unsuitable for posting to a public mailing list. > They have already generated massive new problems for interoperability, not merely between Fortran and C, but between C++ and C. I have just spent 8-10 hours beating my head against one of the latter. The situation is likely to get worse, and is nothing to do with changes to Fortran. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Hubert Ritzdorf 15 Mar '13

15 Mar '13

Hi, I'm still developing MPI and I'm also implementing the mpi_f08 module. My concern in connection with BIND(C) are the routines which use character strings (for example MPI_Error_string()).. My Intel compiler aborts the compilation for these functions with A character dummy argument with length other than 1 is not interoperable I think, that this is correct (but I possibly missed some info on future changes in TSxxxxx). (Nick mentioned in a previous e-mail: "(C) Default CHARACTER is supported only if KIND(' ') is equal to C_CHAR. However, that will almost certainly be the case." I don't know whether this statement fits to the error message above. But almost was true also for the LOGICAL case). Or is this another class of routines which don't support BIND(C) ? What's about future developments in C and Fortran ? May they generate new problems for BIND(C) or less problems (i.e. is there a coordinated standardization effort between Fortran and C in order to reduce the interoperability problems) ? Hubert ________________________________________ From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mpi3-fortran-bounces(a)lists.mpi-forum.org] on behalf of Rolf Rabenseifner [rabenseifner(a)hlrs.de] Sent: Thursday, March 14, 2013 10:14 PM To: mpi3-fortran(a)lists.mpi-forum.org Cc: Kathryn Mohror; Martin Schulz Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind 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) _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran Click https://www.mailcontrol.com/sr/eSeCHIBjlfjGX2PQPOmvUrxf8JpNKDSoYT63dMHV2KIm… to report this email as spam.

1 0

Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Craig Rasmussen 15 Mar '13

15 Mar '13

On Mar 10, 2013, at 10:18 PM, 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. Yes, I believe that removing BIND(C) entirely makes it virtually impossible for the tools community. Not only is there the underscore issue but some implementors want to put the code in modules which makes name mangling MUCH worse. I think the best solution is to add on to Rolf's proposal for problem A. The addition is that there must also be a BIND(C) interface for the tools community that replaces default LOGICAL with INTEGER(C_INT). The overloaded version (INTEGER(C_INT)) will be called by implementor so that it can be intercepted by PMPI users. Martin, do you see a problem with this? It adds an additional wrapper call, one that you don't see. If you like we could have a phone conversation today between you and I. Then perhaps a group conference call the week of March 25. -craig

1 0