<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 15 Feb 2018 at 16:16, Arthur O&#39;Dwyer &lt;<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; 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">&lt;<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>&gt;</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">&lt;<a href="mailto:daveed@edg.com" target="_blank">daveed@edg.com</a>&gt;</span> wrote:</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>
&gt; On Feb 15, 2018, at 5:14 PM, Myria &lt;<a href="mailto:myriachan@gmail.com" target="_blank">myriachan@gmail.com</a>&gt; wrote:<br>
&gt;<br></span><span>
&gt; I&#39;m personally on the side of defining signed overflow as wrapping,<br>
&gt; but compiler people do have a point that it would inhibit<br>
&gt; 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&#39;s P0907 in which I would propose &quot;just the good bits&quot; — namely, remove sign-magnitude and ones&#39;-complement from the standard, and perhaps give defined behavior to (-1 &lt;&lt; 1) and (-1 &gt;&gt; 1), but conservatively retain the undefined behavior of (INT_MAX + 1) and (1 &lt;&lt; 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&#39;m (provisionally) in favor of that. I hope that JF&#39;s paper will have two effects:</div><div><br></div><div> * if any implementers support non-two&#39;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, &quot;I want to add these things, or take remedial action if that would overflow&quot; or &quot;I want to perform arithmetic in the ring of integers modulo 2^N and (somehow) signed arithmetic makes sense in my model&quot;) 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>