<div dir="ltr">Forwarding... I think I can&#39;t email this list from my @<a href="http://apple.com">apple.com</a> address.<div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">JF Bastien</b> <span dir="ltr">&lt;<a href="mailto:jfbastien@apple.com">jfbastien@apple.com</a>&gt;</span><br>Date: Thu, Feb 15, 2018 at 6:26 PM<br>Subject: Re: [ub] A proposal to define signed overflow submitted?<br>To: Richard Smith &lt;<a href="mailto:richardsmith@googlers.com">richardsmith@googlers.com</a>&gt;<br>Cc: ub &lt;<a href="mailto:ub@open-std.org">ub@open-std.org</a>&gt;<br><br><br><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Feb 15, 2018, at 16:47, Richard Smith &lt;<a href="mailto:richardsmith@googlers.com" target="_blank">richardsmith@googlers.com</a>&gt; wrote:</div><br class="m_-4367245972073062076Apple-interchange-newline"><div><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" target="_blank">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.<wbr>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”</div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>Fine by me. The only bit I expect to be contended is signed integer overflow as I propose, so I’m not sure how much of a paper you’ll have. I have the arguments for and against my proposal ready, and intend to present both sides already.</div><br><blockquote type="cite"><div><div dir="ltr"><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"><div>— 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),</div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>I think this is all non-contended. Happy to hear otherwise.</div><br><blockquote type="cite"><div><div dir="ltr"><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"><div>but conservatively retain the undefined behavior of (INT_MAX + 1)</div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>That’s the point of contention I expected :)</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><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"><div>and (1 &lt;&lt; 100).</div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div>Yes, this is really out of scope because existing ISAs do different things.</div><br><blockquote type="cite"><div><div dir="ltr"><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"><div>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></div></div></blockquote><div><br></div><div>That’s one of my goals.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>Another goal I had was to get that discussion going in EWG.</div><div><br></div><div>Please come prepared with specific &quot;optimization lost&quot; numbers, as well as &quot;bugs found&quot;!</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>Oh yes! I’d like to hear people’s ideas here. Basically, ~nobody really opts into UB with signed overflow, they just happen to never hit it dynamically. If we had a way to opt-in or opt-out then I think we’d be better off. I have ideas of how I’d do this, hinted at in paper, but part of this paper’s goal is to hear others’ ideas.</div><br><blockquote type="cite"><div><div dir="ltr"><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"><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>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/ub</a><br>
</blockquote></div></div>
</div></blockquote></div><br></div></div><br></div></div>