I know we didn't want to change the API of MPI_Wait because scope of the call to MPI_Wait may not have access to buf. However, your example does have access to buf so why not just overload MPI_Wait to take an additional argument: CALL MPI_Wait(rq, buf1) CALL MPI_Wait(rq, buf2) ! from an MPI perspective this has no effect as the request has already been satisfied Although this could be a little slower than a call to MPI_F_SYNC_REG as the library has to look at the rq argument. -craig On Apr 19, 2011, at 2:35 PM, Van Snyder wrote:

On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote:

...

With CALL MPI_Irecv(buf, rq) CALL MPI_Wait(rq) CALL MPI_F_SYNC_REG(buf) xnew=buf

The content of MPI_F_SYNC_REG is outside the scope of the Fortran optimization. I do not see that the compiler is allowed to move "xnew=buf" before the MPI_Wait statement because "MPI_F_SYNC_REG(buf)" may have modified the content of buf.

Therefore the problem is solved.

Correct?

If not, please can you show a detailed code, how such a compiled code could work and in xnew is at the end ***not*** the value that was stored in buf by MPI_Wait.

If this works, why not change the Fortran -> MPI interface for MPI_Wait to include "buf" instead of attaching the TARGET attribute to "buf" and hoping the processor will guess that implies that a pointer to "buf" might be hiding in "rq"? After all, the processor can see "rq" and its type (which might actually be TYPE(*)?), so it might (reasonably) conclude from its analysis that "rq" doesn't contain any pointers to "buf".

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran