<br><font size=2 face="sans-serif">This test actually came directly from
the MPI2.2 updates. :)</font>
<br>
<br><font size=2 face="sans-serif">And I full agree that attributes are
too complicated, and it's even worse when mixing fortran and C.</font>
<br>
<br><font size=2 face="sans-serif">Joe's proposal fixes things in MPICH,
but I don't know if you want to implement it or not. It also cleans up
some MPICH code too.</font>
<br>
<br><font size=2 face="sans-serif"><br>
Brian Smith<br>
BlueGene MPI Development<br>
IBM Rochester<br>
Phone: 507 253 4717<br>
smithbr@us.ibm.com<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Rajeev Thakur&quot;
&lt;thakur@mcs.anl.gov&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: mpich2-dev-bounces@mcs.anl.gov</font>
<p><font size=1 face="sans-serif">07/24/2009 05:27 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
mpich2-dev@mcs.anl.gov</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">&lt;mpich2-dev@mcs.anl.gov&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [mpich2-dev] fandcattrf90 test on
BGP</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">This attribute stuff in MPI is
too complicated. One should check that any change does not violate any
of the cases outlined in the clarifying examples being added to MPI 2.2.
See ticket 55: </font><a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55"><font size=2 color=blue face="Arial"><u>https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55</u></font></a>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Rajeev</font>
<br><font size=3>&nbsp;</font>
<br>
<br>
<hr><font size=2 face="Tahoma"><b>From:</b> mpich2-dev-bounces@mcs.anl.gov
[mailto:mpich2-dev-bounces@mcs.anl.gov] <b>On Behalf Of </b>Joe Ratterman<b><br>
Sent:</b> Tuesday, July 21, 2009 9:59 AM<b><br>
To:</b> mpich2-dev@mcs.anl.gov<b><br>
Subject:</b> Re: [mpich2-dev] fandcattrf90 test on BGP</font><font size=3><br>
</font>
<br><font size=3>I think I agree that the the third would be a Fint, but
I don't understand this stuff either. &nbsp;There are three types of attributes.
</font>
<br><font size=3>MPIR_ATTR_AINT</font>
<br><font size=3>MPIR_ATTR_PTR</font>
<br><font size=3>MPIR_ATTR_INT</font>
<br><font size=3>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. &nbsp;I thought it was in put/get for C, but I don't see it now.</font>
<br>
<br><a href=https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/src/mpi/attr/comm_get_attr.c><font size=3 color=blue><u>https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/src/mpi/attr/comm_get_attr.c</u></font></a>
<br><font size=3>MPI_Comm_get_attr has a small pile of code to select the
correct version and handle it correctly:</font>
<br>
<br><font size=3>&nbsp; &nbsp;if (p-&gt;keyval-&gt;handle == comm_keyval)
{</font>
<br><font size=3>*flag &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;= 1;</font>
<br><font size=3>if (outAttrType == MPIR_ATTR_PTR) {</font>
<br><font size=3>&nbsp; &nbsp;if (p-&gt;attrType == MPIR_ATTR_INT) {</font>
<br><font size=3>/* This is the tricky case: if the system is</font>
<br><font size=3>bigendian, and we have to return a pointer to</font>
<br><font size=3>an int, then we may need to point to the </font>
<br><font size=3>correct location in the word. */</font>
<br><font size=3>#if defined(WORDS_LITTLEENDIAN) || (SIZEOF_VOID_P == SIZEOF_INT)</font>
<br><font size=3>*(void**)attribute_val = &amp;(p-&gt;value);</font>
<br><font size=3>#else</font>
<br><font size=3>int *p_loc = (int *)&amp;(p-&gt;value);</font>
<br><font size=3>#if SIZEOF_VOID_P == 2 * SIZEOF_INT</font>
<br><font size=3>p_loc++;</font>
<br><font size=3>#else </font>
<br><font size=3>#error Expected sizeof(void*) to be either sizeof(int)
or 2*sizeof(int)</font>
<br><font size=3>#endif</font>
<br><font size=3>*(void **)attribute_val = p_loc;</font>
<br><font size=3>#endif</font>
<br><font size=3>&nbsp; &nbsp;}</font>
<br><font size=3>&nbsp; &nbsp;else if (p-&gt;attrType == MPIR_ATTR_AINT)
{</font>
<br><font size=3>*(void**)attribute_val = &amp;(p-&gt;value);</font>
<br><font size=3>&nbsp; &nbsp;}</font>
<br><font size=3>&nbsp; &nbsp;else {</font>
<br><font size=3>*(void**)attribute_val = (p-&gt;value);</font>
<br><font size=3>&nbsp; &nbsp;}</font>
<br><font size=3>}</font>
<br><font size=3>else</font>
<br><font size=3>&nbsp; &nbsp;*(void**)attribute_val = (p-&gt;value);</font>
<br>
<br><font size=3>break;</font>
<br><font size=3>&nbsp; &nbsp;}</font>
<br>
<br><font size=3>The part that handles a larger void* than int, and especially
the endian-ness part, would be easier with a union. &nbsp;Since the Aint
and the void* are different on our system, it would help that too.</font>
<br>
<br><font size=3><br>
Joe Ratterman</font><font size=3 color=blue><u><br>
</u></font><a href=mailto:jratt@us.ibm.com><font size=3 color=blue><u>jratt@us.ibm.com</u></font></a>
<br>
<br><font size=3><br>
On Mon, Jul 20, 2009 at 5:37 PM, Dave Goodell &lt;</font><a href=mailto:goodell@mcs.anl.gov target=_blank><font size=3 color=blue><u>goodell@mcs.anl.gov</u></font></a><font size=3>&gt;
wrote:</font>
<br><font size=3>On Jul 16, 2009, at 4:55 PM, Joe Ratterman wrote:<br>
</font>
<br><font size=3>(This is a re-send; I got a pile of python errors on the
last try)</font>
<br>
<br><font size=3>Sorry about that. &nbsp;The IT department here upgraded
both Trac and SVN last week and it didn't go as smoothly as it could have.
&nbsp;Those problems should all be resolved at this point. </font>
<br><font size=3><br>
</font>
<br><a href=https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrf90.f90 target=_blank><font size=3 color=blue><u>https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrf90.f90</u></font></a><font size=3 color=blue><u><br>
</u></font><a href=https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrc.c target=_blank><font size=3 color=blue><u>https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrc.c</u></font></a><font size=3><br>
<br>
This test creates an attribute in F90, sets it in F90, and then reads it
back in C. &nbsp;It was getting the wrong answer:<br>
Expected: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 5555 (0x15b3)<br>
Actual: &nbsp; 23858543329280 (0x15b300000000)</font>
<br><font size=3>... </font>
<br>
<br><font size=3>One idea that strikes me as really good is to change the
&quot;value&quot; field in the MPID_Attribute structure to be a union of
int, void*, and MPI_Aint types with three different names. &nbsp;That would
get rid of the interesting work that is required to handle 8-byte void*
and 4-byte ints. &nbsp;It would also make it easier to add MPI_Aint changes.
&nbsp;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. &nbsp;You already track the data type, so
you would know into which element the attribute should be stored.<br>
<br>
Comments or questions?</font>
<br>
<br><font size=3>Sorry for the delayed response, I was hoping that someone
else who knows and likes attributes better than I do would jump in here.
&nbsp;Unfortunately, that doesn't seem to be happening, so I'll take a
stab at this.<br>
<br>
Do you really mean that the value union should be this?<br>
--------8&lt;---------<br>
union {<br>
 MPI_Fint &nbsp;f_int; /* instead of int */<br>
 void &nbsp; &nbsp; *void_p;<br>
 MPI_Aint &nbsp;a_int;<br>
} value;<br>
--------8&lt;---------<br>
<br>
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?).
&nbsp;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.<br>
<br>
-Dave<br>
<br>
[1] </font><a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55" target=_blank><font size=3 color=blue><u>https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55</u></font></a><font size=3><br>
</font>
<br>
<br>