[MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846

[Rasmussen, Craig E]

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
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran