<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>