Jeff Squyres wrote:
A tangled Fortran issue came up at the Atlanta MPI Forum meeting today, in the context of discussing the (contentious) proposal about a new C MPI_Count datatype. The gist of the proposal is that count parameters are currently int in the C bindings and INTEGER in all Fortran bindings. The proposal is to have a C type MPI_Count that would allow a C implementation to define the back-end type to be 64 bits in order to allow counts larger than 2^31.
*** NOTE: There are (many) issues with the proposed C MPI_Count type; let's not go into them here. I'm asking a Fortran question.
The proposed MPI-3 explicit bindings can easily accommodate a new MPI_Count type. So there's no problem there.
However, there are issues with having a large count type in the implicit interfaces in mpif.h. INTEGER*8 could be used for the count parameter type because all compilers support it, but it's not part of the language (right?). Members of the Forum today felt that using KIND parameters would be ugly because these are supposed to be Fortran-77 style bindings (although I believe you have all drummed into me before that all current Fortran compilers, even those that have an executable name with "77" in it, grok KIND typing just fine).
Since no one has bitten, I'll throw out an initial volley... INTEGER*8 is not part of any Fortran standard - though the * notation is popular in old codes and supported by many vendors. A standard alternative would be integer(selected_int_kind(18)) The Fortran 2008 standard explicitly requires that at least one integer kind support 18 digits. [Possibly the ultimate example of standardizing existing practice.] I'm sure there is some difference of opinion on what is meant by "Fortran 77 style interfaces". My opinion is that such interfaces are free to use more modern syntax and parameterized intrinsic types. The restriction is that only argument passing mechanisms, data types, and kinds of arrays that were in f77 should be allowed. Basically, derived types and dummy argument declarations that would force the caller to have a visible interface are not allowed.
This discussion led to the question: should we even keep extending the mpif.h implicit interfaces?
It seems that there is a spectrum of 4 options:
1. Deprecate mpif.h and MPI's implicit Fortran interfaces. This is NOT removing mpif.h support from the spec or any implementation -- deprecating just states that the standard *MAY* remove them sometime in the future. If we went this route, I'm sure that it would be a LOOOOONG time before mpif.h is removed from the spec because of the millions of lines of existing MPI codes out there that use it.
The Fortran standard has had the concept of deprecated (we call them "obsolescent") and deleted features. In practice, this has been something of a flop, especially deleted features. There are always old codes out there that have to be supported, so vendors do not have the luxury of actually deleting a feature from the compiler. So identifying a feature as deleted or obsolescent is more of a style statement, with no real effect.
2. Don't deprecate mpif.h, but do not include any new MPI-3 functionality in it. This is really only a minor distinction from deprecating; it's just a slightly less-strong statement meant to assure Fortran programmers that we are NOT abandoning mpif.h. However, the road to all new MPI-3 functionality is via the proposed MPI-3 explicit bindings (i.e., "use mpi3").
I like this better than (1) - it is more honest. It makes it clear that mpif.h will continue to work in legacy codes, which I think is an important message.
3. Include all new MPI-3 functionality in mpif.h *except* for the "large count" functionality. This allows mpif.h-using applications to get most of the MPI-3 goodness, with the exception that only INTEGER counts will be supported. If your app needs larger counts than that, you must "use mpi3".
I suspect there could be more "exceptions" uncovered as work progressed. I think it is simpler to be all one way or the other.
4. Include all new MPI-3 functionality in mpif.h, including "large count" functionality.
This one has the potential to break existing programs because of an argument kind mismatch. One could make the argument that this would motivate users to migrate to 'use mpi3' more quickly, but there are often barriers to making such changes (code recertification, too many files involved, ...). Unpleasant visions of geezers with pitch forks storming my cubicle....
What is everyone's opinion on which (1-4) the Forum should go with?
My first choice would be to go with (2). Stopping updates to mpif.h (i.e. rejecting options (3) or (4)) has the advantages of -- Encouraging people to migrate to the module which is superior to an include file in many ways (even if there were no new features), -- Not disrupting any old codes that might be hard to change, and -- Avoids the work, and possible mistakes, of actually changing the text of mpif.h. Anyone writing a new code should be encouraged to use the module. Anyone adding usage of a new feature to an existing code already has to edit the file involved, so making the include -> use transition at the same time is a minimal additional burden. Cheers, Bill -- 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