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

[Simon Baldwin]

H.J. Lu wrote:
> 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.
>   


I think the wisest course for now is to roll back this change until I 
have a better understanding of the issues.  There's obviously a case 
here that's not going be rare overall, and with which the additional 
front-end warning cannot cope well in its current form.

I'm putting together the roll back change.  It should be done in a short 
while.

Thanks all for the comments and feedback here.