[mpich2-dev] fandcattrf90 test on BGP

Dave Goodell goodell at mcs.anl.gov
Mon Jul 20 17:37:14 CDT 2009


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



More information about the mpich2-dev mailing list