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 20 Mar '13

20 Mar '13

On 3/20/13 12:17 PM, Jeff Squyres (jsquyres) wrote: > On Mar 20, 2013, at 8:01 AM, Bill Long <longb(a)cray.com> wrote: > >>>> integer(C_request) :: request >> >> This is correct for mpich. OpenMPI would evidently have a different version. But the concept is still the same - make a correct interface to the C library routine, however it is defined by the implementation, and then call that from a thin Fortran wrapper that takes care of the issues related to LOGICAL, the use of default INTEGER, and OPTIONAL arguments. > > > Instead of integer(c_request), is there a way to standardize on a type that can be implementation-defined? That way, a tool doesn't have to figure out integer vs. <something_else>. > > It would be terrible to force a tool to figure out the type that they're supposed to use. I'm assuming that the tool only cares about the C functions, so the type is MPI_request, as defined in the mpi.h file, which differs for each implementation. I assume the tools already know how to deal with this (by looking in mpi.h). For mpich, this is in mpi.h: typedef int MPI_Request; and in my mpi_C_types module I define C_request to be C_int from the ISO_C_Binding module, which makes it portable across Fortran compilers (for mpich). Using integer(C_Request) in the interfaces allows the mpi.h definition to change (to 'long', for example) with only one line of change in the modules. If the C prototype explicitly says 'int' then I use integer(C_int), but for the typedefs I include this extra layer of abstraction (all eliminated by the compiler). At one point Fortran did have a typedef-like facility (early in the Fortran 2003 development; it was removed before the final version). The Cray compiler actually still has this implemented, so I could have defined a Fortran MPI_Result and used type(MPI_Result) for the C function arguments, but that would not be portable across Fortran compilers. A related tool question is the handling of OPTIONAL arguments. If the tool is expected to handle the Fortran wrappers directly, and you do not have BIND(C) on the wrapper, then this is a complication because the implementation of optional arguments without BIND(C) is different among Fortran compilers. Another argument for having the tools ignore the Fortran wrappers. Cheers, Bill > -- 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 Jeff Squyres (jsquyres) 20 Mar '13

20 Mar '13

On Mar 20, 2013, at 8:01 AM, Bill Long <longb(a)cray.com> wrote: >>> integer(C_request) :: request > > This is correct for mpich. OpenMPI would evidently have a different version. But the concept is still the same - make a correct interface to the C library routine, however it is defined by the implementation, and then call that from a thin Fortran wrapper that takes care of the issues related to LOGICAL, the use of default INTEGER, and OPTIONAL arguments. Instead of integer(c_request), is there a way to standardize on a type that can be implementation-defined? That way, a tool doesn't have to figure out integer vs. <something_else>. It would be terrible to force a tool to figure out the type that they're supposed to use. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

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

20 Mar '13

This mail contains a proposal how we can solve the current Fortran problems and possibly making the tools people also happy. I need at least answers for - mpich (Bill Long), - OpenMPI (Jeff or Craig), - some tools people. Let me summarize what I've learnt so far for mpi_f08: - #364 about LOGICAL correction is a must. - MPI-3.0 allows BIND(C) and non-BIND(C), with the new restrictions in #364 - BIND(C) needs TR29113, therefore any implementation now should use non-BIND(C) for all non-TR29113 compilers. - Most (or all) try to use the non-BIND(C) interface. - Best way to do this are thin wrappers in Fortran that internally call - the oficial MPI-3.0 C binding (here, the tools people have a problem because they expect to wrap the Fortran interface and may therefore double-wrap), or - or an internal MPI-3.0 C routine (which is half-perfect for the tools folk, because they have to handle the implementation-dependant Fortran names with underscores). - And at least Bill wants to include the Fortran MPI library routines itselves in the mpi_f08 module. This is in conflict with the current MPI-3.0 linker naming rules. Implications and proposal: - We should rewrite the linker names section MPI-3.0 17.1.5 with following goals: - Allow additionally to define that the PMPI is provided only on the MPI C interface and the Fortran MPI routines internally call the C interface; again, a macro definition in mpi.h tells whether this is chosen. Question: Would this cause a problem when linking a C or Fortran user application with some own MPI_Test etc. profiling routines that internally call PMPI_Test? - If Fortran profiling is done through the MPI C binding then there are no rules about the Fortran linker names needed, and therefore, one may put the thin Fortran wrappers into a Fortran module. - We can define BIND(C) for MPI routine groups as a future option that is currently not used. This would reduce the current effort for the tools people. Is there anybody who wants to implement one of the Fortran routine groups with BIND(C)? I would expect, that this is the best to solve the problem that #364 prohibits BIND(C) for some routines and implementors want to do the same method for all routines. Don't forget that BIND(C) and TR29113 is still important for implementing these thin wrappers internally. Without using BIND(C) on the official mpi_f08 and mpi module interface, some features of TR29113 are not used: - the extension for interoperabple CHARACTER(LEN=*), - the extension for OPTIONAL dummy arguments. Other TR29113 features are heavily used: - The DIMENSION(..), TYPE(*) is needed for some internal C-written MPI_Isend_desc. - The ASYNCHRONOUS usage for communication buffers. Should we go in this direction? Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Wednesday, March 20, 2013 4:01:52 PM > Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > On 3/20/13 8:26 AM, Jeff Squyres (jsquyres) wrote: > > On Mar 20, 2013, at 6:25 AM, Bill Long <longb(a)cray.com> wrote: > > > >> interface !--> MPI_Test > >> > >> ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status > >> *status); > >> > >> Function MPI_Test_C( request, flag, status) & > >> BIND(C, name="MPI_Test") RESULT (res) > >> import :: C_request, c_int, MPI_Status_C > >> integer(C_request) :: request > > > > This is not correct. You cannot assume that MPI handles are integers > > (they're pointers in Open MPI). > > > This is correct for mpich. OpenMPI would evidently have a different > version. But the concept is still the same - make a correct interface > to the C library routine, however it is defined by the implementation, > and then call that from a thin Fortran wrapper that takes care of the > issues related to LOGICAL, the use of default INTEGER, and OPTIONAL > arguments. > > Cheers, > Bill > > > > > > -- > 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] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 20 Mar '13

20 Mar '13

On 3/20/13 8:26 AM, Jeff Squyres (jsquyres) wrote: > On Mar 20, 2013, at 6:25 AM, Bill Long <longb(a)cray.com> wrote: > >> interface !--> MPI_Test >> >> ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status *status); >> >> Function MPI_Test_C( request, flag, status) & >> BIND(C, name="MPI_Test") RESULT (res) >> import :: C_request, c_int, MPI_Status_C >> integer(C_request) :: request > > This is not correct. You cannot assume that MPI handles are integers (they're pointers in Open MPI). This is correct for mpich. OpenMPI would evidently have a different version. But the concept is still the same - make a correct interface to the C library routine, however it is defined by the implementation, and then call that from a thin Fortran wrapper that takes care of the issues related to LOGICAL, the use of default INTEGER, and OPTIONAL arguments. Cheers, Bill > -- 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 Jeff Squyres (jsquyres) 20 Mar '13

20 Mar '13

On Mar 20, 2013, at 6:25 AM, Bill Long <longb(a)cray.com> wrote: > interface !--> MPI_Test > > ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status *status); > > Function MPI_Test_C( request, flag, status) & > BIND(C, name="MPI_Test") RESULT (res) > import :: C_request, c_int, MPI_Status_C > integer(C_request) :: request This is not correct. You cannot assume that MPI handles are integers (they're pointers in Open MPI). -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

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

20 Mar '13

I would argue that it is simpler, and much more logical (no pun intended) to separate the issues cleanly, with only one wrapper layer. Here is my example: Interface for the actual C library routine using BIND(C), external name = MPI_Test interface !--> MPI_Test ! int MPI_Test(MPI_Request *request, int *flag, MPI_Status *status); Function MPI_Test_C( request, flag, status) & BIND(C, name="MPI_Test") RESULT (res) import :: C_request, c_int, MPI_Status_C integer(C_request) :: request integer(c_int) :: flag type(MPI_Status_C) :: status integer(c_int) :: res end Function MPI_Test_C end interface Actual wrapper routine in the mpi_f08 module, no documented external name !--> MPI_Test subroutine MPI_Test (request, flag, status, ierror) use :: mpi_C_interfaces_nobuf, only: C_Request, c_int, MPI_Status_C, MPI_Test_C TYPE(MPI_Request), INTENT(INOUT) :: request LOGICAL, INTENT(OUT) :: flag TYPE(MPI_Status) :: status INTEGER,OPTIONAL, INTENT(OUT) :: ierror integer(C_Request) :: request_c integer(c_int) :: flag_c type(MPI_Status_C) :: status_c integer(c_int) :: res request_c = request%MPI_VAL status_c = status res = MPI_Test_C (request_c, flag_c, status_c) request%MPI_VAL = request_c status = status_c flag = (flag_c /= 0) if (present(ierror)) ierror = res end subroutine MPI_Test The clean separation avoids all of the problems associated with argument size or type mismatches. The tools would intercept ONLY the C routine (which they know how to do already). An optimizing compiler might inline the Fortran wrapper anyway, so the tools design should not rely on it even existing in the final code. The MPI 3 spec needs to have an option to allow for this sort of separation, in which case there should be no requirements on the external names of the Fortran wrappers. Cheers, Bill On 3/20/13 8:10 AM, Jeff Squyres (jsquyres) wrote: > In general, this sounds like the most promising solution. > > However, there is still a major problem. > > If we add a 2nd binding that takes an INTEGER (and therefore can be BIND(C)), it *MUST* have a different symbol than the original BIND(C) interface. > > For example, MPI_TEST currently has the symbol name MPI_Test_f08. Removing BIND(C) from the current MPI_TEST/LOGICAL interface, adding a new MPI_TEST/INTEGER/BIND(C) interface is fine, but the new BIND(C) symbol *MUST* be different than MPI_Test_f08. > > Otherwise, the symbol MPI_Test_f08 in an implementation will be ambiguous; it could refer to the interface with a LOGICAL argument (e.g., in the OMPI v1.7/v1.8 series), or it could refer to the interface with an INTEGER argument (which we can't do until OMPI v1.9, because OMPI has ABI guarantees). These arguments (could) have different sizes. It would be disastrous for a tool to not know which interface it was intercepting. > > > > On Mar 4, 2013, at 4: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 > > -- 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 Jeff Squyres (jsquyres) 20 Mar '13

20 Mar '13

In general, this sounds like the most promising solution. However, there is still a major problem. If we add a 2nd binding that takes an INTEGER (and therefore can be BIND(C)), it *MUST* have a different symbol than the original BIND(C) interface. For example, MPI_TEST currently has the symbol name MPI_Test_f08. Removing BIND(C) from the current MPI_TEST/LOGICAL interface, adding a new MPI_TEST/INTEGER/BIND(C) interface is fine, but the new BIND(C) symbol *MUST* be different than MPI_Test_f08. Otherwise, the symbol MPI_Test_f08 in an implementation will be ambiguous; it could refer to the interface with a LOGICAL argument (e.g., in the OMPI v1.7/v1.8 series), or it could refer to the interface with an INTEGER argument (which we can't do until OMPI v1.9, because OMPI has ABI guarantees). These arguments (could) have different sizes. It would be disastrous for a tool to not know which interface it was intercepting. On Mar 4, 2013, at 4: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/

1 0

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

18 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

1 0

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

17 Mar '13

Hi Craig, all, On Mar 15, 2013, at 10:16 AM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> 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 think we can deal with the underscore issue, but I didn't realize that there as an additional name mangling through the modules - this will really cause problems. > 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. Sorry, didn't see this until today. This does make sense, though, and I think this could work from the tools perspective, although I have to admit I don't know enough to judge the impacts for the Fortran implementations. A group conversation next week on this would be good, although it would have to be Monday for me to make it. The following week would be easier. Thanks, Martin > > -craig > ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

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

16 Mar '13

On 3/15/13 7:46 PM, Craig Rasmussen wrote: > 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. If you implement the worker routine in Fortran then that will require BIND(C) since it will need the correct C interface and name so that C users can call it. For those cases, BIND(C) is definitely required. And you will need to provide the PMPI interface, unless the routine is so trivial that the tools would be uninterested. I'm assuming that is not the case for you example since the goal was 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. > I think some subsequent emails a least partially clarified this. Cheers, Bill > -craig > -- 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