Re: Resurrecting -Wunreachable

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

On Tue, May 6, 2014 at 4:09 PM, Florian Weimer <fweimer@redhat.com> wrote:
> I would like to resurrect -Wunreachable, using an algorithm which is roughly
> based on the Java rules for reachable statements and normal completion,
> augmented to deal with labels and gotos, no-return functions, statement
> expressions, and whatever else is relevant to C and C++.  This analysis
> would be based mostly on syntax (except that constant folding is applied to
> detect trivially infinite loops), so it wouldn't suffer from the dependence
> on target and optimization levels the previous option had to deal with.
>
> I think computing this information is a prerequisite for a high-quality
> switch warning, to detect cases that do not fall through because they do not
> complete normally, but this is a separate matter.
>
> The question I have if it would be feasible right now to implement this as
> an early GIMPLE pass, or if I should bury this project until we have mostly
> eliminated early folding (Jeff Law thinks it's too difficultâ).
>
> As far as I can tell, the target dependence we have in fold right now (see
> <http://gcc.gnu.org/ml/gcc-help/2014-05/msg00014.html>) would not interfere
> too much with Java-style reachability analysis: The CFG is target-dependent,
> but under the Java rules, both branches of an if statement a reachable even
> if the condition is a compile-time constant.  (It makes sense to keep this
> behavior because just as in Java, constant conditions are used for
> conditional compilation in C and C++, it's not always the preprocessor that
> is used for this.)  So I hope that the known target dependency issues would
> not impact the generated warnings.
>
> Comments?

Like I have suggested in the past a good point to do this kind of analysis
on the (mostly, as you say) unoptimized IL is right after going into SSA
form and implementing said analysis as an IPA pass (yeah, that somewhat
conflicts).

From there you can run things like the CCP analysis phase (without
doing any transform) and use the converted CCP lattice to optimize
things (you can also run value-numbering).

If you are fine with getting function-local info only you can get away
with not doing an IPA pass (but you might get info from optimized
bodies leaked into the analysis I think).

Basically look for pass_build_ssa in passes.def and insert your pass
after that (then it's not an IPA pass).  If you want to have IPA passes
at that point you need to re-organize things slightly - I'd suggest
moving pass_init_datastructures and pass_build_ssa into
all_lowering_passes so you can add IPA passes to the beginning
of all_small_ipa_passes.

Richard.

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