[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

Argyrios Kyrtzidis kyrtzidis at apple.com
Wed Jan 23 13:56:19 PST 2013


On Jan 23, 2013, at 11:00 AM, David Blaikie <dblaikie at gmail.com> wrote:

>>>> The right way to handle this is with appropriate annotations. This is
>>>> simply
>>>> not a good argument for emitting unreachable.
>>> 
>>> The only reason LLVM/Clang have all those unreachables annotating the
>>> end of functions is because of simplistic GCC warning. For codebases
>>> that build Clang only it seems quite likely that those would not be
>>> present. I don't really see how "users should be annotating these
>>> things" is sufficient - users get all sorts of other optimizations
>>> that the language allows without having to be explicit about that.
>> 
>> 
>> If the only reason the annotations are there is for the simple GCC warning
>> then as Argyrios points out a compiler analysis can do the optimization
>> already.
> 
> Except it can't - the Clang warning optimistically assumes that enums
> can only hold the enumerants but the standard allows them to contain
> all values in the representable value's range. It's perfectly possible
> that the enum could currently have other values - so, sure, we could
> restrict the trap/unreachable to the subset of cases we think have a
> better chance of being actually unreachable but that seems more than a
> tad subtle & we still have bogus results in other cases.

I'm not actually advocating this, but the idea here is not that we would emit an unreachable (in optimized build) after every covered switch, but when after the covered switch the function ends without returning a value.
This would cover the cases where there is no -Wreturn-type warning to force you to add an explicit annotation. Are you thinking of other examples from llvm/clang ?

> 
> - David
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits




More information about the cfe-commits mailing list