* 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

Reply via email to