[cfe-commits] r165273 - in /cfe/trunk: lib/CodeGen/CodeGenFunction.cpp test/CodeGen/catch-undef-behavior.c test/CodeGenCXX/catch-undef-behavior.cpp test/CodeGenCXX/return.cpp

[Chandler Carruth]

On Tue, Jan 22, 2013 at 5:42 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>wrote:

> On Jan 22, 2013, at 5:23 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> On Tue, Jan 22, 2013 at 4:15 PM, Daniel Dunbar <daniel at zuster.org> 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.

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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130122/ac296d22/attachment.html>