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: > + > +<blockquote> > +<pre> > +/* 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: > MPI_DATATYPE_NULL > + // 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.: > > [...snipped...] > 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. Cool. > *** 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. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
