On Jul 31, 2012, at 2:58 AM, Eugene Loh wrote:

> The main issue is this.  If I go to ompi/mpi/fortran/mpif-h, I see six files 
> (*recv_f and *probe_f) that take status arguments.  Normally, we do some 
> conversion between Fortran and C status arguments.  These files test if 
> OMPI_SIZEOF_FORTRAN_INTEGER==SIZEOF_INT, however, and bypass the conversion 
> if the two types of integers are the same size.  The problem with this is 
> that while the structures may be the same size, the C status has a size_t in 
> it.  So, while the Fortran INTEGER array can start on any 4-byte alignment, 
> the C status can end up with a 64-bit pointer on a 4-byte alignment.  That's 
> not pleasant in general and can incur some serious hand-slapping on SPARC.  
> Specifically, SPARC/-m64 errors out on *probe and *recv with MPI_PROC_NULL 
> sources.  Would it be all right if I removed these "shorts cuts"?

Ew.  Yes.  You're right.

What specifically do you propose?  I don't remember offhand if the status 
conversion macros are the same as the regular int/INTEGER conversion macros -- 
we want to keep the no-op behavior for the regular int/INTEGER conversion 
macros and only handle the conversion of MPI_Status separately, I think.  
Specifically: for MPI_Status, we can probably still have those shortcuts for 
the int/INTEGERs, but treat the copying to the size_t separately.  

Thanks for fixing the ibm MPROBE tests, btw.  Further proof that I must have 
been clinically insane when I added all those tests.  :-(

Related issue: do we need to (conditionally) add padding for the size_t in the 
Fortran array?

> Here are two more smaller issues.  I'm pretty sure about them and can make 
> the appropriate changes, but if someone wants to give feedback...
> 
> 1)  If I look at, say, the v1.7 MPI_Mprobe man page, it says:
> 
>     A  matching  probe  with  MPI_PROC_NULL  as  source  returns
>     message  =  MPI_MESSAGE_NULL...
> 
> In contrast, if I look at ibm/pt2pt/mprobe_mpifh.f90, it's checking the 
> message to be MPI_MESSAGE_NO_PROC.  Further, if I look at the source code, 
> mprobe.c seems to set the message to "no proc".  So, I take it the man page 
> is wrong?  It should say "message = MPI_MESSAGE_NO_PROC"?

Oh, yes -- I think the man page is wrong.  The issue here is that the original 
MPI-3 proposal said to return MESSAGE_NULL, but this turns out to be ambiguous. 
 So we amended the original MPI-3 proposal with the new constant 
MPI_MESSAGE_NO_PROC.  So I think we fixed the implementation, but accidentally 
left the man page saying MESSAGE_NULL.

If you care, here's the specifics:

https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/38
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/328

> 2)  Next, looking further at mprobe.c, it looks like this:
> 
> int MPI_Mprobe(int source, int tag, MPI_Comm comm,
>               MPI_Message *message, MPI_Status *status)
> {
>    if (MPI_PROC_NULL == source) {
>        if (MPI_STATUS_IGNORE != status) {
>            *status = ompi_request_empty.req_status;
>            *message = &ompi_message_no_proc.message;
>        }
>        return MPI_SUCCESS;
>    }
>    ......
> }
> 
> This means that if source==MPI_PROC_NULL and status==MPI_STATUS_IGNORE, the 
> message does not get set.  The assignment to *message should be moved outside 
> the status check, right?

Agreed.  Good catch.

Do the IBM MPROBE tests check for this condition?  If not, we should probably 
extend them to do so.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/


Reply via email to