<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_attr">On Sat, 26 Jan 2019 at 08:54 Marc Glisse &lt;<a href="mailto:marc.glisse@inria.fr">marc.glisse@inria.fr</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>