Aleksandar Donev wrote:
On Thursday 27 March 2008 07:53, Hubert Ritzdorf wrote:
This is what some vendors already implemented (using different names). When I remember (and understood) it correctly, you mentioned that they didn't it right.
They have not integrated it with the rest of the standard. You can do many things that apparently work fine until you try them with polymorphic assumed-shape arrays of a parameterized derived type (yes, Fortran has those). A standard has to be internally fully self-consistent...it cannot just say "oh, no one will do that, just make it work".
Since the behaviour should be well-defined if an interface description is not available and the vendors have to implement it, and it should be possible to specify it for a single argument.
The existing standard says the following about implicit interfaces. A routine's interface can be omitted, however, the interface exists and there is a *unique* interface (modulo some attributes that can be omitted). That is, an MPI_Send routine, which exists somewhere, according to the Fortran standard, has to either accept an integer buffer or a real buffer. It cannot accept both. There is a *unique* interface. If the interface is implicit, it is up to the user to ensure the actual arguments actually match the type/rank etc. of the dummy. If it is explicit, the compiler helps check it. That is the ONLY difference between implicit and explicit interfaces.
Now, compilers often allow users to violate the standard and call MPI_Send with both a real and an integer buffer array, and they either do not do any analysis to detect it, or if they do, they offer a compiler switch to say "close your eyes please". It is however, not conforming to the Fortran standard, period.
I don't believe that the compiler guys have introduced such compiler switches only for MPI since also other libraries have such problems. And I have also seen compiler switches for "don't perform copy-in/copy out". And I see Fortran codes transferring scalar arguments such as "my_array (1,1)" (nevertheless many data items are transferred) in order to avoid copy in/copy out.
There are 2 general problems for MPI with these copy-in/copy-out behaviour:
I understand the problems it causes with MPI. But, it also make a lot of wonderful things work in Fortran. You cannot remove it from Fortran just to accommodate MPI. Saying "don't do copy in/out" will only work if you specify, in details, what to do about situations where copy in/out is required. Should we disallow those situations (i.e., put rules like "the actual argument shall not be..."). Do some existing Fortran codes rely on copy in/out, for example:
CALL MPI_Send(my_array(1,:),...) ! Will copy column 1 into a contig buffer
I agree that there may be Fortran application codes which are using this. But this would probably not work for MPI_Isend. And this is the main problem. The application programmers cannot always decide what the compiler is doing and whether the MPI calls will work or not.
Should we now make those programs non-conforming? I am not offering answers here, I am pointing out that explicit answers are required.
I think, that it must be possible to explicitly define what is performed at the subroutine interface so that the application programmer AND the compiler explicitly knows what the other partner expects. The C_LOC functionality is not far away from this requirement and the ASYNCHRONOUS attribute also avoids any copying of the actual argument. Best regards Hubert