On Tue, Jan 22, 2013 at 5:55 PM, Chandler Carruth <[email protected]>wrote:
> On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis > <[email protected]>wrote: > >> On Jan 22, 2013, at 5:23 PM, Chandler Carruth <[email protected]> >> wrote: >> >> On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <[email protected]> wrote: >> >>> Hi Richard, >>> >>> I object pretty strongly to using unreachable here for C++ code bases. >>> >> >> There was some discussion surrounding this, and I'm still pretty strongly >> in favor of it... >> >> >> IMHO you still haven't given enough justification; your proposed >> optimization opportunity in >> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/025326.html is >> specific to a full covered switch, which can be handled with an >> optimization that targets this case. >> > > 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. > The right way to handle this is with appropriate annotations. This is simply not a good argument for emitting unreachable. 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. > I'd much prefer llvm.trap in all cases instead of unreachable, although I still don't see much value in forcing users to fix code that from their perspective "works". - Daniel > > 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. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
