Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] MPI_Mprobe
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-07-31 08:15:22

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:

> 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
For corporate legal information go to: