This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should -Wmaybe-uninitialized be included in -Wall?


What about introducing a new blanket warning kind that excludes
anything with false positives? something like -WALL ?

David

On Wed, Jul 10, 2013 at 3:51 AM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
> Jeff Law <law@redhat.com> writes:
>
>> On 07/09/2013 07:56 AM, Andreas Arnez wrote:
>>> Andrew Haley <aph@redhat.com> writes:
>>>
>>>> On 07/09/2013 12:59 PM, Andreas Arnez wrote:
>>>>> With this situation at hand, I wonder whether it's a good idea to keep
>>>>> maybe-uninitialized included in -Wall.  Projects which have been using
>>>>> "-Wall -Werror" successfully for many years are now forced to
>>>>> investigate non-existing bugs in their code.
>>>>
>>>> But maybe-uninitialized is very useful, and it's not really inappropriate
>>>> for -Wall.
>>>
>>> The warning would be extremely useful, if false positives didn't obscure
>>> real problems.  In its current state I consider its usefulness limited.
>> Depends on your point of view.  This topic has been hashed through
>> repeatedly on this list.
>
> OK, I may be biased, because I have *only* seen false positives with
> this warning so far.  Others may have made better experience with it.
>
>> I personally like -Wall -Werror.  While we do run into false positives
>> and the set of false positives does change from release to release as
>> a result of optimizations, I believe there's been an overall
>> improvement in the quality of the codebases that use -Wall -Werror.
>
> Yes, I fully agree on the usefulness of -Wall -Werror and its
> contribution to the code base quality increase.
>
>> I certainly see fewer bugs these days blamed on the compiler which are
>> in fact uninitialized variables.
>
> That's good.  But there are still some known false positives with "maybe
> uninitialized".  If there weren't, then this option could go away and be
> covered by -Wuninitialized instead.
>
>> I'd like to revamp how we do path isolation to eliminate more of the
>> false positives, but this warning is by its nature going to generate
>> false positives.
>
> Right, that's the point.  My understanding of -Wall (so far) was that it
> shouldn't include warnings with false positives.
>
>> What I would ask is that folks continue to file bugs for false
>> positives.  While I can't guarantee we'll fix them, they do provide a
>> good base of tests for path sensitive analysis.
>
> Yes, I can see how the current policy of including this warning in -Wall
> may help getting more coverage.
>
>> I'd also suggest that when an initialization is added merely to avoid
>> the warning that a comment be added to the code so that folks know
>> it's merely to avoid the warning.
>
> Adding a bogus initialization is usually not a reasonable response to
> this warning anyway.  For instance, consider cases where certain
> elements of an array (like in bug 57832) or of a large struct (like
> reported in bug 55288) are falsely claimed to "may be uninitialized".
> Also consider cases where -Wmaybe-uninitialized reported the wrong
> variable, like in bug 55985.  Besides, a bogus initialization would also
> obscure helpful warnings, like those emitted from "-Wuninitialized".
>
> OK, it appears that most people (silently or explicitly) accept the
> inclusion of warnings with false positives in -Wall.  I'm not hung up on
> this.  It would just be nice to reflect this appropriately in the
> documentation.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]