Bernhard R. Link - Re: -Wuninitialized issues (original) (raw)

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

• From: "Bernhard R. Link"
• To: gcc at gcc dot gnu dot org
• Date: Wed, 2 Nov 2005 20:29:37 +0100
• Subject: Re: -Wuninitialized issues
• References: <Pine.LNX.4.61.0511021147580.14971@nondot.org>

• Chris Lattner sabre@nondot.org [051102 19:28]:

  Jeff Law wrote:

  I prefer consistency in warnings, regardless of optimization level. I disagree and I think we have a significant contingency of users that would disagree -- if optimizations allow us to avoid false-positive warnings, then we should use that information to avoid those false positive warnings.

  Jeff, I completely agree with you for some class of users (users being developers who use GCC but don't hack on GCC itself).

  OTOH, there is also a very large class of users (like myself) who have to write code that works well across several different compilers. In this capacity, having GCC be clever is not a good thing: if GCC is silent where a less clever compiler will warn, I will have to fix the warning anyway and won't know about it until someone else complains (I use GCC as my primary development compiler).

Why do you have to do something about a warning that is a clear false positive? With code like if( cond ) { sav = x; } bla; if( cond ) x = sav; I'd much prefer a warning about a "may be used uninitialized" on less clever compiler over the change to lose a "is used unitialized" warning some future more clever compiler may find if, say, cond is changed in between. Also placing a unconditional sav=0 before it all to silence it up I will lose any chance to have this found by valgrind.

Prior versions of GCC (and most other compilers) assumed that since somepredicate is passed the address of X, that it may initialize X, thus not emitting a warning at the use site. Newer versions of GCC inline somepredicate and then emit a bogus warning: "X" is only assigned to (and used) in the case where somepredicate returns true, and GCC loses this information (it is probably missing a jump threading opportunity).

While this is surely a regression w.r.t. false positives, I don't see how this is he result of "more clever", but mostly a side effect of better inlining that was not followed by making the warning code better to cope with such inlining.

Hochachtungsvoll, Bernhard R. Link

• References:
  • Re: -Wuninitialized issues
    * From: Chris Lattner