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.
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/