[MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
Rasmussen, Craig E
rasmussn at lanl.gov
Tue Apr 19 16:40:14 CDT 2011
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.
On Apr 19, 2011, at 2:35 PM, Van Snyder wrote:
> On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote:
>> CALL MPI_Irecv(buf, rq)
>> CALL MPI_Wait(rq)
>> CALL MPI_F_SYNC_REG(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.
>> 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
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
More information about the mpiwg-fortran