From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1545 invoked by alias); 3 Sep 2010 14:07:11 -0000 Received: (qmail 32330 invoked by uid 48); 3 Sep 2010 14:06:33 -0000 Date: Fri, 03 Sep 2010 14:07:00 -0000 Message-ID: <20100903140633.32325.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "manu at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-09/txt/msg00453.txt.bz2 ------- 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