Re: [PATCH][RFC] Add a subset of -Warray-bounds warnings to C/C++ front ends

[Paul Koning <Paul_Koning at dell dot com>]

>>>>> "H" == H J Lu <H.J.> writes:

 H> On Fri, May 2, 2008 at 7:06 AM, Mark Mitchell
 H> <mark@codesourcery.com> wrote:
 >> H.J. Lu wrote:
 >> 
 >> 
 >> > A side effect of copying these warnings up into the language
 >> frontends is > that warnings are now printed even if the array
 >> access is in dead or > inaccessible code.
 >> >
 >> 
 >> We've had this discussion for years.  The arguments are:
 >> 
 >> 1. Users only care about problems that actually affect their
 >> build.  Let the optimizers do their thing and warn about problems
 >> that are detected that way.  This avoids warning about things in
 >> dead code, and it results in warnings that occur after (say)
 >> simplifications from inlining.
 >> 
 >> 2. Users care about problems that might occur when building their
 >> code in some different mode.  Users want the same warnings across
 >> platforms, and whether optimizing or not.  Thus, we should emit
 >> warnings only from front ends, without trying to avoid dead code,
 >> and without doing a lot of transformation on the code.
 >> 
 >> GCC has traditionally done (1).  I've argued for (2), which is
 >> what most compilers do.  Simon's patch makes it do a bit of (2),
 >> while still doing (1).  This seems to me like a reasonable
 >> compromise; you give up none of the warnings in (1), but still get
 >> many of the benefits of (2).
 >> 
 >> Obviously, Simon needs to fix the bootstrap issue.  But, I don't
 >> see a fundamental problem with the patch -- at least not yet.
 >> 

 H> If it doesn't work on gcc itself, I don' think it will be much
 H> useful elsewhere.  I suggest

 H> 1. At -O0, the frond-end warning should never be turned into an
 H> error even if -Werror is used since the frond-end doesn't know if
 H> the code will be dead or not.  2, At -O1 and above, the frond-end
 H> warning should be queued and optimizer can remove it from the
 H> queue if the code in question turns out dead.

I don't like this notion at all.

If a bit of code is wrong, I believe it is perfectly reasonable (and
in fact desirable) to call it wrong even if it happens to be
unreachable.

I wouldn't make that a requirement -- it's ok for warnings to come out
of the back end after optimization.  But I don't agree with the notion
that warnings about dead code are bad.

Dead code can come alive with very small source code changes.  As a
matter of good software engineering, it's helpful for warnings to
appear when the bad code is created.  If the warning appears 6 months
later as a side effect of a small change elsewhere, the repair can be
significantly harder.

Also, it seems to me that suppressing warnings as a side effect of
optimization can produce results somewhat like the one we recently
debated at length with CERT.  Not quite the same, but somewhat like
it. 

In other words, I would support Mark's preference for approach #2, for
the same sort of reasons he gave.

    paul