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 <[email protected]> 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 [email protected]

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

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

_______________________________________________ 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