This is the mail archive of the
mailing list for the GCC project.
Re: Resurrecting -Wunreachable
- From: Florian Weimer <fweimer at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: Thu, 08 May 2014 10:21:15 +0200
- Subject: Re: Resurrecting -Wunreachable
- Authentication-results: sourceware.org; auth=none
- References: <5368ED25 dot 7090901 at redhat dot com> <CAFiYyc0+1TwHdez4hiop=PVyebTArswFKfebDPwAn_xpoad=qQ at mail dot gmail dot com> <536A1F83 dot 5050703 at redhat dot com> <CAFiYyc3U8SjqBFcEf9WKTyi3r1rmLdEagL=q=DJk65fHMS9iKg at mail dot gmail dot com> <536A2213 dot 9020104 at redhat dot com> <CAFiYyc3CUivZGc+fmZqMuYLPbNjA0t0HS5mRbEap3J8GuTWobg at mail dot gmail dot com> <536A26FE dot 7080204 at redhat dot com> <CAFiYyc0T3RkPRX3b8ssHnw_UkhA1k5dTOdAedhkPO1wizzAdWA at mail dot gmail dot com>
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
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.
Florian Weimer / Red Hat Product Security Team