On Apr 14 2011, Rolf Rabenseifner wrote:

this is already handled by all hints about code movement and register optimization in the old MPI-2.2 and in more detail in the upcoming MPI-3.0.

To summarize, there are several options: - TARGET buf - Using a call to a dummy routine MPI_F_SYNC_REG(buf) immediately after MPI_Wait - Storing buf as a module variable or in a common block - (VOALTILE buf, not recommended)

'ASYNCHRONOUS buf' is explicitly not an option, because a Fortran compiler - that implements Fortran asynchronous input/output with blocking I/O routines - is allowed to ignore the ASYNCHRONOUS attribute.

Only compilers with really asynchronous Fortran I/O have to also internally imply the TARGET attribute when the ASYNCHRONOUS attribute is given in the application.

Is my analysis correct?

Not even remotely, I am afraid. Here are some comments:

To summarize, there are several options: - TARGET buf

Why should that work? Fortran compilers are required to take notice of it only when also operating with POINTER variables. And there is nothing stopping them from moving such data dynamically, if they update all associated pointers. That's old technology, after all.

- Using a call to a dummy routine MPI_F_SYNC_REG(buf) immediately after MPI_Wait

That won't work, either, because it doesn't stop copy-in/copy-out and other such techniques.

- Storing buf as a module variable or in a common block

That won't work, either, for the above reason.

...

- (VOALTILE buf, not recommended)

Why should that work any better than ASYNCHRONOUS? All it says (in both C and Fortran, incidentally) is "All bets are off - consult your vendor documentation for what might happen." ASYNCHRONOUS has the right semantics.

'ASYNCHRONOUS buf' is explicitly not an option, because a Fortran compiler - that implements Fortran asynchronous input/output with blocking I/O routines - is allowed to ignore the ASYNCHRONOUS attribute.

If you are being that legalistic, the problem is insoluble in all of C, C++ and Fortran. Sorry, but that IS what the standards say!

Only compilers with really asynchronous Fortran I/O have to also internally imply the TARGET attribute when the ASYNCHRONOUS attribute is giv

Er, no, they don't. The attributes are different and have subtly different properties.

...

You do not need to be a member of J3. Would you like to join interop-tr?

Most of the internals of the TR, I do not understand. As I see, the list moderator can agree to deliver the few mails from me also to the other members of the interop-tr. It isn't a problem for me to put you, Bill, Nick, Craig, and Reinhold on the CC.

The problem is when we reply. Unless I leave you in the list explicitly, you won't see the reply. And duplicating people has other problems. Regards, Nick Maclaren.