<div dir="ltr">Forwarding... I think I can'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"><<a href="mailto:jfbastien@apple.com">jfbastien@apple.com</a>></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 <<a href="mailto:richardsmith@googlers.com">richardsmith@googlers.com</a>><br>Cc: ub <<a href="mailto:ub@open-std.org">ub@open-std.org</a>><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 <<a href="mailto:richardsmith@googlers.com" target="_blank">richardsmith@googlers.com</a>> 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'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">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.<wbr>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”</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'-complement from the standard, and perhaps give defined behavior to (-1 << 1) and (-1 >> 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 << 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'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></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 "optimization lost" numbers, as well as "bugs found"!</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, "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></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>