<div dir="ltr">Dave,<div><br></div><div>Thanks for the detailed response, and for having a much better memory than me.  :)</div><div><br></div><div>Given that MPI_Aint will be at least the same size as ptrdiff_t, do we actually have a problem with subtracting MPI_Aints to find pointer diffs?  It seems like this may actually be ok.</div>
<div><br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 11:57 AM, Dave Goodell (dgoodell) <span dir="ltr"><<a href="mailto:dgoodell@cisco.com" target="_blank">dgoodell@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[The previous version of this was held for moderation, so I subscribed and disabled email delivery.  If you want me to participate in this thread, please keep me CCed.]<br>

<div class="im HOEnZb"><br>
On Dec 20, 2013, at 8:22 AM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>
<br>
</div><div class="im HOEnZb">> Jeff,<br>
><br>
> I don't think that anyone is making an argument that is specific to 32b<br>
> architectures.  The concern is that the MPI standard currently requires:<br>
><br>
> (1) a two's complement architecture where overflow/underflow of signed<br>
> arithmetic on an unsigned quantity always results in the right unsigned<br>
> value<br>
<br>
</div><div class="im HOEnZb">I think the hardware support for two's complement requirement is probably not a major problem, since sign-and-magnitude and one's complement machines seem unlikely to make a resurgence outside of some weird DSPs.  Though the C standard certainly supports all three representations, this aspect is largely academic and not a real issue for the MPI community.<br>

<br>
The larger issue is that the C standard explicitly declares signed integer arithmetic overflow to be undefined.  There are two reasons this is a real concern:<br>
<br>
A) Compilers really do perform optimizations related to signed integer overflow: <a href="http://www.airs.com/blog/archives/120" target="_blank">http://www.airs.com/blog/archives/120</a><br>
<br>
B) Some platforms/compilers can/will trap on signed integer overflow, e.g., GCC with "-ftrapv".<br>
<br>
</div><div class="im HOEnZb">> - OR -<br>
> (2) an MPI_Aint type that is 2x the size of an address to ensure that<br>
> overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary address<br>
> in Fortran)<br>
><br>
> Given that every system I know of falls into category (1) and there is a<br>
> solution (2) for all other systems, I am not trying to recall why we felt<br>
> that this problem needs to be solved through new arithmetic routines.  I<br>
> believe there was a concern that 128-bit integers are not standard and not<br>
> well supported by most languages/architectures, so (2) may not be a<br>
> workable solution.  Maybe Dave G [added to cc] remembers our rationale?<br>
<br>
</div><div class="HOEnZb"><div class="h5">Systems don't seem to have easily-used, portable language support for >64-bit integer math right now.  Even in C11 the largest minimum sizes are only 64-bit; anything else is an extension or a choice to define "long long" as larger.  I just checked a 64-bit x86_64 Linux system here at Cisco and couldn't find an obvious 128-bit signed integer type in a couple of minutes of looking.<br>

<br>
Also, though the MPI_BOTTOM issue is annoying, it's irrelevant.  There's nothing to prevent an operating system from giving you an address with the most significant bit set, so you have the problem even if MPI_BOTTOM==0 everywhere.  Indeed, I just saw a bug report fly by the other day with a such an address (0xffffffff7d3ca461) on Solaris: <a href="http://www.open-mpi.org/community/lists/users/2013/12/23149.php" target="_blank">http://www.open-mpi.org/community/lists/users/2013/12/23149.php</a><br>

<br>
So I agree with Jim that (2) is not a workable solution.<br>
<br>
-Dave<br>
<br>
</div></div></blockquote></div><br></div>