On May 30, 2012, at 7:04 PM, Dmitri Gribenko wrote:
> +<li><tt>must_be_null</tt> specifies that the expression should be a null
> +pointer constant, for example:
> +/* In mpi.h */
> +extern struct mpi_datatype mpi_datatype_null
> + __attribute__(( type_tag_for_datatype(mpi, void, must_be_null) ));
> +#define MPI_DATATYPE_NULL ((MPI_Datatype) &mpi_datatype_null)
> +/* In user code */
> +MPI_Send(buffer, 1, MPI_DATATYPE_NULL /*, ... */); // warning:
> + // was specified but buffer
> + // is not a null pointer
I'm not sure that this is a warning we want to set.
MPI_<foo>_NULL constants are defined as "invalid handles" -- in most cases, it's an error to pass them to an MPI function (e.g., the MPI_Send example, above, would generate an MPI exception). They're usually used for comparison.
I can't think of a case offhand where it's acceptable to pass MPI_DATATYPE_NULL to an MPI function. I could be missing something, though... (actually, I guess I can think of some cases -- we have some regression test programs that specifically pass MPI_DATATYPE_NULL, just to ensure that it properly invokes an MPI exception)
But even so, if one passes MPI_DATATYPE_NULL, the buffer and count arguments will be ignored. So I don't think that we want to require that MPI_DATATYPE_NULL *requires* a NULL pointer.
> *** JMS What happens if the argument type is (void*)? Does that match
> the tag type? E.g.:
> If a function is passed a type tag (that is, MPI_Datatype) that does
> not have an annotation, then that function call is not checked. That
> is, in MPI_Send(buf, 1, MPI_BYTE, ...) buf can be of any pointer type.
All the above sounds good.
> *** JMS I'm a bit confused as to why 2int got a tag, but the others
> did not. We do have C equivalents for all types -- do you need a
> listing of the configure results where we figured out all the C
> equivalents? (i.e., I can look them up for you -- our configury
> is a bit... deep :-) )
> I did not annotate them because those are Fortran types. If there are
> some known C equivalents in OpenMPI, I will happily add them. But
> please note that if these equivalents are discovered during configure,
> we can not hardcode them into mpi.h.in. Some autoconf macros will be
> needed probably.
We should have AC macros for all of these already.
The point of this is because all MPI datatypes are available in all languages, meaning that I could MPI_Send an MPI_INTEGER from fortran and receive it in C code (that MPI_Recv's an MPI_INTEGER). FWIW, I've seen apps do this in two general cases:
1. Fortran sends to C, C just holds the blob without looking at/understanding the value, C eventually sends the blob back to Fortran.
2. Fortran sends to C, and C interprets the value because it knows the interoperable type (e.g., sends MPI_INTEGER, receives into a C int).
If the app doesn't know the exact equivalent C type corresponding to the Fortran type (e.g., case 1), they may need one of the examples I provided above (e.g., cast the buffer to (void*)).
> *** JMS Per my question on MPI_Alltoallw, I'm not quite sure how these
> tags work with arrays of datatypes...?
> I removed the incorrect attribute on PMPI_Alltoallw.
> *** What happens if we're compiling C and std::complex<foo> isn't
> defined? I see that <complex> is only defined above #if __cplusplus.
> Then OMPI_ATTR_TYPE_TAG_CXX(type) is defined to be empty and these
> type tags are not checked.
Ah! I missed that it was a different macro (OMPI_ATTR_TYPE_TAG_CPP/CXX). Got it.
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/