Yes, this is the direction we are going for new Fortran bindings in MPI-3. My proposal is specifically for a small/incremental fix for MPI-2.1's existing MPI F90 bindings. The rule for MPI-2.1 is that changes cannot break existing MPI codes. As such, only "small" things are going into MPI-2.1. On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote:

I would recommend that for buffers of variable type and rank that the Fortran interface make use of the Fortran 2003 C interoperability features, supported by many compilers already, and make these arguments of type C_PTR passed by value. The programmer would then pass C_LOC(buffer), where buffer can be of any type and rank. This is all specifiable with standard-conforming syntax.

If this is done, you don't need to have multiple interfaces just to change type, and you're not giving up any type checking that you would have had before, as any combination of type and rank would have matched some interface. Now you can have as many of these "variant" arguments as you like without a mind-numbing series of specific interfaces.

A compiler using this choice must support the following Fortran 2003 features: - Intrinsic module ISO_C_BINDING - The VALUE attribute - The BIND(C) attribute

And if the user chooses a compiler that does not support this, then they can use the F77 interfaces.

Steve Lionel Developer Products Division Intel Corporation Nashua, NH

-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Wednesday, March 05, 2008 9:16 PM To: Mailing list for discussion of MPI 2.1 Cc: MPI-3 Fortran working group Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings Importance: Low

The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*:

- 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers

This is clearly broken.

An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes.

Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway...

If this seems like a good idea, I can write a proper proposal for it. Comments?

-- Jeff Squyres Cisco Systems

_______________________________________________ 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

-- Jeff Squyres Cisco Systems