<div dir="ltr"><div>Greeting again SG12,</div><div dir="ltr"><br></div><div>Here&#39;s another email that I think got trapped for moderation yesterday but apparently can get through now.  Sorry for the additional noise.</div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Scott Schurr<br><a href="mailto:S.Scott.Schurr@gmail.com" target="_blank">S.Scott.Schurr@gmail.com</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 28, 2019 at 10:13 AM Scott Schurr &lt;<a href="mailto:s.scott.schurr@gmail.com">s.scott.schurr@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi John,<div><br></div><div>Nice to hear from you.  Thanks for your interest in the paper.</div><div><br></div><div>Regarding whether &quot;can&#39;t happen&quot; is a behavior, I&#39;m expecting to hear varied well studied opinions (like yours) during the paper discussion.  My perspective is that &quot;can&#39;t happen&quot; cannot be defined in a mechanistic way.  It&#39;s not like, &quot;The gear used to turn left but now turns right.&quot;  However I think that &quot;can&#39;t happen&quot; can be defined in the sense that the result of an explosion can be quite well defined.  Given an explosion of sufficient yield at a certain location there is a high probability that the building will collapse, but we&#39;re uncertain where the individual bricks will fall.  We still understand the outcome sufficiently well to be able to talk about it.</div><div><br></div><div>My feeling is that it&#39;s not that different from talking about race conditions.  We really don&#39;t know what the consequence of a race condition will be.  But we can define a race condition.</div><div><br></div><div>Thanks for your thoughts.</div><div><br clear="all"><div><div dir="ltr" class="gmail-m_-8062042179736955175gmail_signature">Scott Schurr<br><a href="mailto:S.Scott.Schurr@gmail.com" target="_blank">S.Scott.Schurr@gmail.com</a></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 26, 2019 at 2:13 AM John McFarlane &lt;<a href="mailto:john@mcfarlane.name" target="_blank">john@mcfarlane.name</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>When I read that title, I also had the reaction &quot;you have the wrong target&quot; but in my case, I assumed the target was SG20. I think it&#39;s a great paper to send to that study group.<br></div><div><br></div><div>My main concern, though, boils down to the idea that &quot;Can&#39;t happen&quot; is somehow a behaviour. It seems to be suggested, for example, that overflow as it occurs in current implementations can realistically be defined. I&#39;m not sure that&#39;s practical because such behaviour is highly sensitive to many non-obvious factors. Overflow at a single point in the code may produce wildly different &#39;behaviours&#39; depending on factors such as: from where it&#39;s invoked, various toolchain options and minor revisions to the implementation. And even with this information at hand, the write-up might well be onerous to the implementer and worse than useless for the user because it would involve describing in much detail the optimization algorithms involved. So I don&#39;t think implementation-defined is a straight-forward solution to the problem.<br></div><div><br></div><div>Generally, I agree I&#39;d like to see effort put toward thinking of the correct way to deliver the idea of UB. It&#39;s the wrong wording to give to users of the language. It&#39;s implementor speak. Like a bailiff using legalese to explain why somebody has just lost their home, it causes confusion and anger.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-8062042179736955175gmail-m_-5861978000361409311gmail_attr">On Sat, 26 Jan 2019 at 08:54 Marc Glisse &lt;<a href="mailto:marc.glisse@inria.fr" target="_blank">marc.glisse@inria.fr</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
just a couple points missing from the paper:<br>
<br>
1) with g++-7 -O2 -Wall, the motivating example on the left produces:<br>
<br>
&lt;source&gt;: In function &#39;int32_t add_100_without_wrap(int32_t)&#39;:<br>
&lt;source&gt;:8:3: warning: assuming signed overflow does not occur when assuming that (X + c) &lt; X is always false [-Wstrict-overflow]<br>
    if (ret &lt; a)<br>
<br>
However, we removed the warning from gcc-8 because it was too noisy and <br>
impossible to work around when the optimization is what you actually want.<br>
<br>
2) At least with gcc, -ftrapv doesn&#39;t really work. You need <br>
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error for <br>
something roughly equivalent to what -ftrapv is supposed to do.<br>
<br>
<br>
Now my opinion: you have the wrong target. Compilers that have a -fwrapv <br>
option (or -ftrapv or ubsan or ...) already indirectly describe the <br>
default behavior as undefined (and the standard already describes it as <br>
undefined), so it is already documented. Adding a sentence or 2 in the <br>
standard and on pages that nobody reads won&#39;t help. It seems that you want <br>
to talk either to teachers, so they warn their students more about the <br>
properties of signed overflow, or to compiler writers, to convince them to <br>
change the default to -fwrapv or -ftrapv (I hope they don&#39;t) or add more <br>
warnings.<br>
<br>
-- <br>
Marc Glisse<br>
_______________________________________________<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>
</blockquote></div></div>
</blockquote></div></div>