* Chris Lattner <[EMAIL PROTECTED]> [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