Re: Resurrecting -Wunreachable

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, May 8, 2014 at 10:21 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 05/07/2014 02:43 PM, Richard Biener wrote:
>
>>> The more challenging issue with early GIMPLE is that loops have already
>>> been
>>> lowered to gotos, so adopting the syntax-based Java reachability rules is
>>> impossible.  Oh dear.
>>
>>
>> Perfect is the enemy of the good (no false positives and no false
>> negatives).  I don't think you can get all you want starting at GIMPLE.
>> And the "earlier" you start the more you need to implement a whole
>> compiler.
>
>
> We already had an unreachable code warning at a later stage in the compiler.
> Its reporting was so confusing that it head to be removed.  I don't think
> this approach works.
>
>
>> And you have of course to precisely define what you consider
>> "unreachable" (considering a global const bool debug = true/false; and
>> if (debug) guarded code - compared to using the preprocessor).
>
>
> I plan to follow the Java rules, with necessary adjustments due to language
> differences:
>
> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21>
>
> They are based on syntax (except for the infinite loop case), so they are
> much more predictable from a developer perspective.
>
> There are other warnings which benefit greatly from information collected
> during optimization, but unreachable code doesn't.

Then I suggest to implement this warning in the frontends - as surely
you'll have differently modified "Java rules" for different frontends.
At the time a frontend calls cgraph_finalize_function () its AST is
supposed to be in GENERIC (+ FE extensions to GENERIC) form
(so for Fortran it's already lowered too much I guess).  So that could
be a (kind-of) common point to implement this for C/C++ at least.

Richard.

>
> --
> Florian Weimer / Red Hat Product Security Team