[mpich2-dev] fandcattrf90 test on BGP

[Joe Ratterman]

I think I agree that the the third would be a Fint, but I don't understand
this stuff either.  There are three types of attributes.MPIR_ATTR_AINT
MPIR_ATTR_PTR
MPIR_ATTR_INT
An attribute created in C is a PTR, in Fortran it is an AINT, and the
depricated put/get interface in Fortran sets the type to INT.  I thought it
was in put/get for C, but I don't see it now.

https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/src/mpi/attr/comm_get_attr.c
MPI_Comm_get_attr has a small pile of code to select the correct version and
handle it correctly:

    if (p->keyval->handle == comm_keyval) {
*flag                  = 1;
if (outAttrType == MPIR_ATTR_PTR) {
    if (p->attrType == MPIR_ATTR_INT) {
/* This is the tricky case: if the system is
 bigendian, and we have to return a pointer to
 an int, then we may need to point to the
 correct location in the word. */
#if defined(WORDS_LITTLEENDIAN) || (SIZEOF_VOID_P == SIZEOF_INT)
*(void**)attribute_val = &(p->value);
#else
int *p_loc = (int *)&(p->value);
#if SIZEOF_VOID_P == 2 * SIZEOF_INT
p_loc++;
#else
#error Expected sizeof(void*) to be either sizeof(int) or 2*sizeof(int)
#endif
*(void **)attribute_val = p_loc;
#endif
    }
    else if (p->attrType == MPIR_ATTR_AINT) {
*(void**)attribute_val = &(p->value);
    }
    else {
*(void**)attribute_val = (p->value);
    }
}
else
    *(void**)attribute_val = (p->value);

break;
    }

The part that handles a larger void* than int, and especially the
endian-ness part, would be easier with a union.  Since the Aint and the
void* are different on our system, it would help that too.


Joe Ratterman
jratt at us.ibm.com


On Mon, Jul 20, 2009 at 5:37 PM, Dave Goodell <goodell at mcs.anl.gov> wrote:

> On Jul 16, 2009, at 4:55 PM, Joe Ratterman wrote:
>
>  (This is a re-send; I got a pile of python errors on the last try)
>>
>
> Sorry about that.  The IT department here upgraded both Trac and SVN last
> week and it didn't go as smoothly as it could have.  Those problems should
> all be resolved at this point.
>
>
>> https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrf90.f90
>>
>> https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrc.c
>>
>> This test creates an attribute in F90, sets it in F90, and then reads it
>> back in C.  It was getting the wrong answer:
>> Expected:           5555 (0x15b3)
>> Actual:   23858543329280 (0x15b300000000)
>>
> ...
>
>> One idea that strikes me as really good is to change the "value" field in
>> the MPID_Attribute structure to be a union of int, void*, and MPI_Aint types
>> with three different names.  That would get rid of the interesting work that
>> is required to handle 8-byte void* and 4-byte ints.  It would also make it
>> easier to add MPI_Aint changes.  You wouldn't have to worry about the
>> strangeness of storing an integer type in a pointer type, and it would
>> automatically handle any differences in the sizes of the elements.  You
>> already track the data type, so you would know into which element the
>> attribute should be stored.
>>
>> Comments or questions?
>>
>
> Sorry for the delayed response, I was hoping that someone else who knows
> and likes attributes better than I do would jump in here.  Unfortunately,
> that doesn't seem to be happening, so I'll take a stab at this.
>
> Do you really mean that the value union should be this?
> --------8<---------
> union {
>  MPI_Fint  f_int; /* instead of int */
>  void     *void_p;
>  MPI_Aint  a_int;
> } value;
> --------8<---------
>
> This seems reasonable to me on its face, but I would feel better if someone
> who was more active in MPI Forum ticket #55 [1] thought so too (Rajeev?).
>  This is a really complicated section of the standard that always confuses
> me on at least one or two issues every time I look at it.
>
> -Dave
>
> [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich2-dev/attachments/20090721/3e69dd34/attachment.htm>