On Thu, May 31, 2012 at 2:07 PM, Jeff Squyres <jsquyres_at_[hidden]> 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 <gribozavr_at_[hidden]>*/
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}