This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Add a subset of -Warray-bounds warnings to C/C++ front ends
>>>>> "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