On Thu, May 31, 2012 at 2:07 PM, Jeff Squyres <[email protected]> wrote:
> 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)
I usually pass <NULL, MPI_DATATYPE_NULL> as arguments which are
"significant only at root" and that function call is not in the root
process code path.
> 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.
It just doesn't make sense to pass non-null pointer and
MPI_DATATYPE_NULL (because null pointer will be ignored). Hence the
warning.
>> *** 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.
OK, I'll try find them to support (1) usecase described below.
> 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*)).
Agreed.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <[email protected]>*/
