[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable

["manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #22 from manu at gcc dot gnu dot org  2010-09-03 14:06 -------
(In reply to comment #21)
> (In reply to comment #8)
> > Is 'coverity' a compiler? I don't think so.
> > 
> 
> Coverity is not a tool that generates code, but it does perform
> all the syntactic & semantic analysis that a code-generating compiler will.
> Then, it goes beyond that with further static analysis.

GCC is not designed to be used as a static analysis tool. This doesn't mean it
wouldn't be interesting to be able to reuse GCC analysis modules for doing
that. Other compilers have shown that it is possible and a desirable feature
[*]. However, GCC is not designed to be reusable, there is none working on a
similar thing for GCC, and no sign that any existing GCC developer will start
working on it in the near future. Unless someone new starts working on this,
don't expect anything similar from GCC.

[*] http://clang-analyzer.llvm.org/

> > Do you have actual examples of
> > *compilers* which, everything taken into account, decided to make sure this
> > case is worth warning?
> 
> That's the worst argument I've read in a long time.
> Do we need proof that another compiler does something before the gcc 
> team will take it up now?

There is more work to do in GCC than people willing (or being paid) to do it,
so if there is some indication that some feature may be impossible or too
expensive to implement, existing GCC developers will probably focus their
efforts on something else more feasible. If you can show that another compiler
is able to do it in an efficient way, that shows that it is feasible. As far as
I know, GCC has always been a very conservative compiler in terms of features,
not a source of innovation. So yes, showing a working implementation seems to
be a necessary condition (but not a sufficient one).

In fact, it is common practice to check what other compilers do in order to
verify a bug, and it is useful information in bug reports.

I am sorry for this flamewar. I hope I clarified all the issues and the wiki
[**] contains a more detailed discussion about the technical issues related to
uninitialized warnings in case anyone is willing to help to solve them.

[**] http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884