* 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
