From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16448 invoked by alias); 12 Nov 2012 21:11:57 -0000 Received: (qmail 16395 invoked by uid 48); 12 Nov 2012 21:11:44 -0000 From: "scovich at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/55288] Improve handling/suppression of maybe-uninitialized warnings Date: Mon, 12 Nov 2012 21:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: scovich at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-11/txt/msg01063.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 --- Comment #2 from Ryan Johnson 2012-11-12 21:11:43 UTC --- (In reply to comment #1) > Why don't just initialize the variable? It seems simpler than implementing yet > another special attribute in GCC. In the original program, the "variable" is a largish struct, the function is hot, and the 'valid' execution path is not the most common one. Avoiding unnecessary initialization there has a measurable impact on performance. Note that, in other parts of the code that gcc understands better, the initialization is unnecessary (no warning) and gets optimized away even if I do have it in place... much to my chagrin once, after I did a lot of work to refactor a complex function, only to realize that gcc emitted *exactly* the same machine code afterward, because it had already noticed and eliminated the dead stores. There's also a philosophical argument to be made... if we agree that all warnings subject to false positives should be supressible, the current mechanism for maybe-uninitialized is inadequate, and a variable attribute would resolve the issue very nicely. There's precedent for this: you *could* use #ifndef NDEBUG (or even pragma diagnostic) to avoid unused-variable warnings for helper variables used by multiple assertions scattered over a region of code, but setting ((unused)) on the offending variable is much easier to read and maintain, while still allowing other unused variables to be flagged properly.