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: [email protected] [[email protected]] on behalf of Rolf Rabenseifner [[email protected]] Sent: Thursday, March 14, 2013 10:14 PM To: [email protected] 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" <[email protected]> To: [email protected] Cc: [email protected], "Kathryn Mohror" <[email protected]>, "Nick Maclaren" <[email protected]> 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 <[email protected]> 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" <[email protected]> To: "MPI-3 Fortran working group" <[email protected]> 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Bill Long [email protected] 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 [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran Click https://www.mailcontrol.com/sr/eSeCHIBjlfjGX2PQPOmvUrxf8JpNKDSoYT63dMHV2KImQ... to report this email as spam.