<div dir="ltr">On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.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 style="word-wrap:break-word"><div><div class="im"><div>On Jan 22, 2013, at 5:23 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Richard,<div><br></div><div>I object pretty strongly to using unreachable here for C++ code bases.</div>

</div></blockquote><div><br></div><div>There was some discussion surrounding this, and I'm still pretty strongly in favor of it...</div></div></div></div></blockquote><div><br></div></div><div>IMHO you still haven't given enough justification; your proposed optimization opportunity in <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html</a> is specific to a full covered switch, which can be handled with an optimization that targets this case.</div>
</div></div></blockquote><div><br></div><div style>It is applicable to any circumstance where there is a programmer-known invariant that all paths terminate in a return which is not statically determinable. I've seen both predicated code with if/else chains of this form, and switches.</div>
<div style><br></div><div style>But I actually think we're approaching this from the wrong direction. The C++ standard is extremely clear that this is UB. Given that, I think we should aggressively tell users about this problem with their code. If the optimization benefits aren't worthwhile, then I would argue for emitting llvm.trap in *all* cases rather than just in non-optimized builds. While I think the optimization benefits are both easy to get and worth it, I don't have a collection of benchmarks that rely on it so I'm not going to fight tooth and nail for it. I just don't understand sacrificing it when we don't have to.</div>
<div style><br></div><div style><br></div><div style>However, if you're arguing that Clang should define the behavior of falling off the end of a function in C++ as an extension, I think that requires significant evidence of the problems this causes and following the usual Clang policies a move toward defining the behavior in the standard. I think the biggest problem with that is going to be coming up with a useful, rational description of what this defined behavior is in the C++ language. There are many differences between C++ and C here that (IMO) make it very challenging to specify.<br>
</div></div></div></div>