<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 22, 2013, at 5:55 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><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; position: static; z-index: auto; "><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></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></div></div></blockquote><div><br></div><div>This is in user code that doesn't get a -Wreturn-type warning (thus forcing putting an 'unreachable' in source code which is a "Good Thing"(TM) because it makes the invariant explicit) ? Could you give a non-switch example ?</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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.</div></div></div></div></blockquote><div><br></div><div>Ok, but emitting 'unreachable' does not in any way "tell users about this problem with their code", it's doing the opposite, it takes a bug and messes up the code beyond hope of recognition for the problem.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style=""> 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.</div></div></div></div></blockquote><div><br></div><div>FWIW, I don't have a strong opinion on this, as long as the trap is not treated like unreachable by the backend.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">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></blockquote><div><br></div><div>Standardizing the behavior in the language is related but a bit off-topic, maybe another thread should be started; this is about the specific changes in the clang frontend.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="">
</div></div></div></div>
_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits<br></blockquote></div><br></body></html>