[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

[Daniel Dunbar]

On Tue, Jan 22, 2013 at 5:55 PM, Chandler Carruth <chandlerc at google.com>wrote:

> 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.
>

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