[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [PATCH][RFC] Add a subset of -Warray-bounds warnings to C/C++ front ends
From:       "H.J. Lu" <hjl.tools () gmail ! com>
Date:       2008-05-02 16:04:15
Message-ID: 6dc9ffc80805020904x2db5d923wf742e47dc68c9742 () mail ! gmail ! com
[Download RAW message or body]

On Fri, May 2, 2008 at 7:06 AM, Mark Mitchell <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.
>

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

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


H.J.
[prev in list] [next in list] [prev in thread] [next in thread]