On Thu, May 8, 2014 at 10:21 AM, Florian Weimer <fwei...@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
