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: mpi3-fortran-bounces_at_[hidden] [mailto:mpi3-fortran-bounces_at_[hidden]] 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 mpi3-fortran_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran