<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-07-12 11:17 GMT-07:00 Peter Lawrence via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David,<br>
          Here is the definition accepted by Hal of what we’re doing<br>
<br>
> 1. Sometimes there are abstraction penalties in C++ code<br>
> 2. That can be optimized away after template instantiation, function inlining, etc<br>
> 3. When they for example exhibit this pattern<br>
>       if (A) {<br>
>               stuff;<br>
>       } else {<br>
>               other stuff including “undefined behavior”;<br>
>       }<br>
> 4. Where the compiler assumes “undefined behavior” doesn’t actually happen because<br>
>    In the C language standard it is the users responsibility to avoid it<br>
> 5. Therefore in this example the compiler can a) delete the else-clause<br>
>     b) delete the if-cond, c) assume A is true and propagate that information<br>
<br>
<br>
<br>
We are actively deleting undefined behavior, and the question is why<br>
given that doing so potentially masks a real source code bug.<br>
At the very least deleting undefined behavior should not be the default.<br></blockquote><div><br></div><div>I don't believe it is the default today: optimizations aren't turned on unless you opt-in.</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div>