<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 15 Feb 2018 at 16:16, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Thu, Feb 15, 2018 at 3:51 PM, Hubert Tong <span dir="ltr"><<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Feb 15, 2018 at 6:44 PM, David Vandevoorde <span dir="ltr"><<a href="mailto:daveed@edg.com" target="_blank">daveed@edg.com</a>></span> wrote:</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>
> On Feb 15, 2018, at 5:14 PM, Myria <<a href="mailto:myriachan@gmail.com" target="_blank">myriachan@gmail.com</a>> wrote:<br>
><br></span><span>
> I'm personally on the side of defining signed overflow as wrapping,<br>
> but compiler people do have a point that it would inhibit<br>
> optimizations in certain cases involving signed integers.<br>
<br>
</span></span><span>My understanding is that it kills a significant optimization opportunity (that is currently taken advantage of by compilers).<br></span></blockquote><div>I also believe that it makes it harder for tooling to flag unintentional signed overflow.<br></div></div></div></div></blockquote><div><br></div><div>Yes.</div><div><br></div><div>I am considering writing a response to JF's P0907 in which I would propose "just the good bits" — namely, remove sign-magnitude and ones'-complement from the standard, and perhaps give defined behavior to (-1 << 1) and (-1 >> 1), but conservatively retain the undefined behavior of (INT_MAX + 1) and (1 << 100). I think such a conservative proposal might stand a chance these days; it feels analogous to the removal of trigraphs.</div><div>Defining (INT_MAX+1 == INT_MIN), as proposed by P0907? No, that will never happen in a million years.</div></div></div></div></blockquote><div><br></div><div>I'm (provisionally) in favor of that. I hope that JF's paper will have two effects:</div><div><br></div><div> * if any implementers support non-two's-complement targets, they step forward and speak up</div><div> * the arguments in favor of keeping overflow undefined (for static and dynamic analysis, optimization, mathematical reasoning) and in favor of making it defined (ease of writing overflow checks, giving defined-but-maybe-wrong behavior to overflowing code rather than allowing unbounded badness) are enumerated</div><div><br></div><div>... and in particular, for the common cases where people want defined signed overflow behavior (eg, "I want to add these things, or take remedial action if that would overflow" or "I want to perform arithmetic in the ring of integers modulo 2^N and (somehow) signed arithmetic makes sense in my model") we can add a concise and easy way of expressing that intent.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>However, I personally will not be at JAX, and if someone beats me to writing this paper, I will not be upset. :)</div><div><br></div><div>–Arthur</div></div></div></div>
_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org" target="_blank">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/ub</a><br>
</blockquote></div></div>