Hi, Aleksandar Donev wrote:

Hi,

Not to be argumentative, take this as IMO please.

On Friday 21 March 2008 05:13, Hubert Ritzdorf wrote:

...

MPI and Fortran 77 have worked without any problems

Except for the problem that the MPI Forum chose to completely ignore and violate ALL existing Fortran standards. This *includes* Fortran 77. All Fortran versions are strictly typed and passing a REAL array to an INTEGER argument has never been, nor will it ever be legal.

...

Thus, an attribute for an argument "Behave such as without interface description

Then don't supply an interface? Or simply say

VOID :: buffer

for the actual just to give it a name. I already commented on this earlier.

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. 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. It's fine for me to have such a VOID attribute.

...

and don't perform copy-in/copy-out"

What if the actual argument is a strided (non-contiguous) array or, say, an array constructor? The Fortran committee did not invent copy-in/copy-out because compilers wanted to do copy frivolously. It is a necessary implementation method to pass certain types of actuals to certain types of dummies. You have to explicitly address this and cannot just say "go back to Fortran 77". New Fortran has strided arrays, array constructors, array pointers, etc., etc., like it or not.

There are 2 general problems for MPI with these copy-in/copy-out behaviour: (*) In non-blocking MPI communication routines, the buffers may be received or sent after the MPI routine which specifies the buffer has already finished. If the compiler issues a copy-in/copy out of that buffer before/after that MPI routine, this causes incorrect results. I.e. the data is read from or written to memory which is already used by other tasks. Even if the application programmer is aware of this and has ensured that the data is stored in consecutive/contiguous memory addresses, it happens that the compiler performs a copy-in/copy-out before/after these MPI routines. Thus, a major problem for the application programmer is that there is no possibility to specify this to the interface description so that the compiler doesn't perform copy-in/copy out. A second major problem is that the application program may work for a long time with this copy-in/copy-out behaviour for non-blocking MPI routines. But small changes in the run-time behaviour of the application program may cause errors (incorrect results/segmentation violations) in other (far away) parts of the application programs which are very very hard to find/debug. (*) Derived MPI datatypes are defined as sequence of primitive types and byte displacements. The byte displacements (which might be negative) are relative to the buffer specified in the MPI function call. (If the MPI_BOTTOM is specified as MPI buffer, you can see the byte displacements as memory addresses). In order to compute these displacements for general derived datatypes, function MPI_Get_address should be called. Again copy-in before MPI_Get_address or copy-in/copy-out before/after a MPI communication subroutine call might cause incorrect results because the memory layout of the generated MPI derived datatype and the memory layout which was generated by the compiler before/after the MPI communication call might be totally different. Even if the application programmer defines MPI derived datatype correctly, he cannot control the behaviour of the application program since he doesn't know at which places the compiler creates temporary memory in order to perform copy-in/copy-out. Best regards Hubert