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 Jeff Squyres (jsquyres) 05 Mar '13

05 Mar '13

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/

1 0

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

04 Mar '13

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

1 0

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

04 Mar '13

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

1 0

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

04 Mar '13

On 3/2/13 3:10 AM, N.M. Maclaren wrote: > >> The even worse problem with default INTEGER is that some users will >> compile their Fortran codes with options like -r8 -i8, leading to the >> near certainty that in at least one case, KIND(0) will not be the same >> as C_INT. You need two copies of the .mod file for the module - one >> for 32-bit default integers, and the other for 64-bit default >> integers. The source for the module can be the same, you just have to >> compile the module twice, once each with and without the -r8 -i8 >> options. And make sure the compiler points to the right module file >> depending on the -r8 -i8 settings in later compilations. Wrappers and >> "path magic" solve this problem. But it is an artificial problem >> introduced by the use of default INTEGER. > > Bill, we have been here several times before. That particular problem > may be the one that affects you, but it affects very few users of MPI, > and it is the least of small issues as far as the option compatibility > goes. Other than the half-dozen USA mountain-top sites, most MPI users > do not run with more than 2-4 GB per process, because cores and memory > are increasing pro-rata. It is very common to run with one MPI rank for the node, with OpenMP within the node. This is especially common for codes that do not naturally scale well. The node memory is often more that 4GB. But there are other reasons for specifying -i8. Particularly, if you want -r8 for some reason, you also need -i8 unless you want a non-conforming compiler. Just as the size of default INTEGER and LOGICAL are supposed to be the same, also default REAL and INTEGER are equal size - part of the same rule. 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 Tobias Burnus 04 Mar '13

04 Mar '13

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. 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

1 0

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

04 Mar '13

On 3/4/13 12:07 PM, N.M. Maclaren wrote: > On Mar 4 2013, Craig Rasmussen wrote: >> >> Nick, can't the wrapper C code safely cast to an integer (or simple >> assignment after testing for true/false) from a _Bool? >> >> To remove BIND(C) from the MPI-3 interfaces is practically very >> difficult to do because of the PMPI interaces. > > I am not sure what you are proposing. My point is that LOGICAL almost > certainly will not be interoperable (i.e. is not available in BIND(C) > interfaces), and that using _Bool VALUE arguments or results is seriously > problematic, even when moving between two C compilers, let alone a C and > a Fortran one. The use of Fortran-C interoperability the way it was intended would have specified Fortran interfaces directly for the C library routines, with no wrappers needed. For reasons thought important, the MPI group decided to not do that. The BIND(C) on the wrapper interfaces is not really focused on the arguments. It is mainly to define the external name for the subroutine. It is still needed for that, independent of whether there are weird arguments with type LOGICAL. As is the case with default INTEGER, we just make believe that the arguments are interoperable. As a practical matter, it does not matter if the wrapper is in Fortran. > > 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) call mpi_xxx_c (cx) x = (cx /= 0) end subroutine sub > > A wrapper written in C can't do anything useful, because there are no > interoperable LOGICAL types except the problematic LOGICAL(C_BOOL). > There are numerous reasons for not writing the wrappers in C. Mainly just good code design - C knows nothing about Fortran types. You want the parts that depend on particulars of the Fortran typing system to be in Fortran. Cheers, Bill > > Regards, > Nick Maclaren. > > > > > > _______________________________________________ > 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 04 Mar '13

04 Mar '13

On Mar 4 2013, Craig Rasmussen wrote: >> >> B) There is no match between Fortran default LOGICAL and anything in >> C. INTEGER(C_INT) has the right storage and wrong semantics; >> LOGICAL(C_BOOL) has the right semantics and wrong storage. >> LOGICAL(C_BOOL) is defined to interoperate with _Bool, but I wouldn't >> trust it an inch. If it is never passed as VALUE, it will probably be >> OK, but I wouldn't bet on it. >> >> Some C compilers will almost certainly quietly convert it to int in >> arguments and results, with a kludge to make sizeof() and the unary '&' >> operator work. Quite a lot have done (still do?) that with integers >> shorter than int and reals shorter that double, to help with K&R >> compatibility. If the Fortran compiler does the same, you are OK, >> but I have seen nasty problems here. >> >> I don't see any practical option but to have non-BIND(C) wrappers. > > Nick, can't the wrapper C code safely cast to an integer (or simple > assignment after testing for true/false) from a _Bool? > > To remove BIND(C) from the MPI-3 interfaces is practically very difficult > to do because of the PMPI interaces. I am not sure what you are proposing. My point is that LOGICAL almost certainly will not be interoperable (i.e. is not available in BIND(C) interfaces), and that using _Bool VALUE arguments or results is seriously problematic, even when moving between two C compilers, let alone a C and a Fortran one. 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). A wrapper written in C can't do anything useful, because there are no interoperable LOGICAL types except the problematic LOGICAL(C_BOOL). Regards, Nick Maclaren.

1 0

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

04 Mar '13

I've commented on a few of Nick's points below: On Mar 1, 2013, at 1:20 PM, N.M. Maclaren wrote: > I am responding to this shorter list because I find it less confusing. > >> The complete list of dummy argument types is: >> >> TYPE(*), DIMENSION(..), ASYNCHRONOUS [checked above] >> TYPE(*), DIMENSION(..) > > No problem, but it does need TS 29113. > >> INTEGER [checked above] >> INTEGER, ASYNCHRONOUS >> INTEGER, DIMENSION(1) >> >> INTEGER(KIND=MPI_OFFSET_KIND) [checked above] >> INTEGER(KIND=MPI_ADDRESS_KIND) [checked above] >> INTEGER(KIND=MPI_ADDRESS_KIND), ASYNCHRONOUS >> INTEGER(KIND=MPI_COUNT_KIND) > > See (A) below. > >> INTEGER, OPTIONAL [checked above] > > No further problem, but it does need TS 29113. > >> LOGICAL [checked above] > > Gug. See (B) below. > >> CHARACTER(LEN=*) [checked above] > > No further problem, but it does need TS 29113. > >> CHARACTER(LEN=MPI_MAX_ERROR_STRING) >> >> CHARACTER(LEN=valuelen) ! with valuelen being another dummy argument > > See (C) below. > >> TYPE(C_PTR), VALUE [checked above] >> TYPE(C_PTR) > > No problem. > >> TYPE(MPI_Comm) [checked above] >> TYPE(MPI_Comm), ASYNCHRONOUS > > See (D) below. > >> TYPE(MPI_Status) [checked above] > > See (E) below. > > > This assumes that BIND(C) is specified on the procedures; if it is not, > implementations may have to provide wrappers, in which case all of these > problems disappear. The difficulties are caused SOLELY by the desire to > use the same functions for both. > > I don't see how that will work, anyway, as BIND(C) passes all non-VALUE > arguments as addresses, and the C interfaces define a lot of them as > values. Communicators are one example, but they are used in almost all > of the calls. > > A) Default INTEGER is, as you say, supported only if it maps to some > C integer type. Because of the attempt to keep the same interfaces for > Fortran and C, I would be chary about a system where KIND(0) was not > equal to C_INT, but that will be the dominating case. This can be handled in the wrapper. Anyone who uses the PMPI interfaces in C will have to take this into account with a typecast (or equivalent means). > > B) There is no match between Fortran default LOGICAL and anything in > C. INTEGER(C_INT) has the right storage and wrong semantics; > LOGICAL(C_BOOL) has the right semantics and wrong storage. > LOGICAL(C_BOOL) is defined to interoperate with _Bool, but I wouldn't > trust it an inch. If it is never passed as VALUE, it will probably be > OK, but I wouldn't bet on it. > > Some C compilers will almost certainly quietly convert it to int in > arguments and results, with a kludge to make sizeof() and the unary '&' > operator work. Quite a lot have done (still do?) that with integers > shorter than int and reals shorter that double, to help with K&R > compatibility. If the Fortran compiler does the same, you are OK, > but I have seen nasty problems here. > > I don't see any practical option but to have non-BIND(C) wrappers. Nick, can't the wrapper C code safely cast to an integer (or simple assignment after testing for true/false) from a _Bool? To remove BIND(C) from the MPI-3 interfaces is practically very difficult to do because of the PMPI interaces. > > C) Default CHARACTER is supported only if KIND(' ') is equal to > C_CHAR. However, that will almost certainly be the case. > > D) These are opaque types, and I don't see a problem. > > E) I don't see a particular problem, though don't even think of > mapping Fortran derived types to C structures unless they are BIND(C)! > Interoperating between two C compilers is bad enough :-( > This is necessary anyway because the MPI handles are dummy arguments in BIND(C) interfaces. -craig

1 0

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

04 Mar '13

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 > > ----- Original Message ----- >> From: "Bill Long" <longb(a)cray.com> >> To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> >> Sent: Monday, March 4, 2013 5:29:24 PM >> Subject: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind >> As an example, this is from page 606 in the spec: >> >> SUBROUTINE MPI_SEND(...) BIND(C,NAME=â€™MPI_Send_fâ€™) >> USE mpi >> CALL PMPI_SEND(...) >> END SUBROUTINE >> >> If you expect to support external linkage names like "MPI_Send_f", >> then >> the BIND(C) is required. >> >> There is no problem with the normal MPI routines since they go through >> wrappers and the wrapper can convert the LOGICAL value into an int for >> sending on to C (and back, if necessary). >> >> The callbacks are more difficult. But there is no need to mess up the >> normal routines, with the associated undesirable side effects. >> >> Cheers, >> Bill >> >> >> >> -------- Original Message -------- >> Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 >> interface - issue with the LOGICAL kind >> Date: Mon, 4 Mar 2013 10:13:36 -0600 >> From: Bill Long <longb(a)cray.com> >> Reply-To: <longb(a)cray.com> >> Organization: Cray Inc. >> To: <mpi3-fortran(a)lists.mpi-forum.org> >> >> >> >> On 3/4/13 9:47 AM, Rolf Rabenseifner 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, >> >> I would be strongly against this, as it prevents putting the wrapper >> routines in a module. We will have to start over from scratch with a >> vastly inferior implementation, with reduced performance. (Unless you >> concurrently delete completely the mpif.h include file, in which case >> the BIND(C) on the wrappers is no needed any longer.) >> >> >>> - 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 >>> >> >> -- >> 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 > -- 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] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind
by Rolf Rabenseifner 04 Mar '13

04 Mar '13

Bill, Without BIND(C), you have to make it according to MPI-3.0 page 605, lines 31-38. Therefore, ticket #364 should work. Please check again. 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: Monday, March 4, 2013 5:29:24 PM > Subject: [MPI3 Fortran] Fwd: Re: Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 interface - issue with the LOGICAL kind > As an example, this is from page 606 in the spec: > > SUBROUTINE MPI_SEND(...) BIND(C,NAME=’MPI_Send_f’) > USE mpi > CALL PMPI_SEND(...) > END SUBROUTINE > > If you expect to support external linkage names like "MPI_Send_f", > then > the BIND(C) is required. > > There is no problem with the normal MPI routines since they go through > wrappers and the wrapper can convert the LOGICAL value into an int for > sending on to C (and back, if necessary). > > The callbacks are more difficult. But there is no need to mess up the > normal routines, with the associated undesirable side effects. > > Cheers, > Bill > > > > -------- Original Message -------- > Subject: Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0:Fortran 2008 > interface - issue with the LOGICAL kind > Date: Mon, 4 Mar 2013 10:13:36 -0600 > From: Bill Long <longb(a)cray.com> > Reply-To: <longb(a)cray.com> > Organization: Cray Inc. > To: <mpi3-fortran(a)lists.mpi-forum.org> > > > > On 3/4/13 9:47 AM, Rolf Rabenseifner 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, > > I would be strongly against this, as it prevents putting the wrapper > routines in a module. We will have to start over from scratch with a > vastly inferior implementation, with reduced performance. (Unless you > concurrently delete completely the mpif.h include file, in which case > the BIND(C) on the wrappers is no needed any longer.) > > > > - 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 > > > > -- > 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