From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3361 invoked by alias); 21 Apr 2011 17:44:12 -0000 Received: (qmail 3351 invoked by uid 22791); 21 Apr 2011 17:44:11 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Apr 2011 17:43:51 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p3LHhoOp000863 for ; Thu, 21 Apr 2011 10:43:50 -0700 Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by wpaz5.hot.corp.google.com with ESMTP id p3LHgaDd013471 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 21 Apr 2011 10:43:49 -0700 Received: by gwb20 with SMTP id 20so746683gwb.17 for ; Thu, 21 Apr 2011 10:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.118.22 with SMTP id q22mr651756ybc.358.1303407828942; Thu, 21 Apr 2011 10:43:48 -0700 (PDT) Received: by 10.150.57.10 with HTTP; Thu, 21 Apr 2011 10:43:48 -0700 (PDT) In-Reply-To: <4DB0679C.9050100@redhat.com> References: <4DB0679C.9050100@redhat.com> Date: Thu, 21 Apr 2011 19:15:00 -0000 Message-ID: Subject: Re: new option -Wno-maybe-uninitialized From: Xinliang David Li To: Jeff Law Cc: GCC Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01808.txt.bz2 On Thu, Apr 21, 2011 at 10:21 AM, Jeff Law wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/07/11 18:24, Xinliang David Li wrote: >> Hi, >> >> the following patch implements the option to fine control the emitted >> warnings -- >> 1) allow suppressing warnings for use of values that may be >> uninitialized. =A0Definitely uninitialized values that may be used >> warning is not affected >> 2) allow fine grain control on promotion of warnings to errors: >> -Wno-error=3Dmaybe-uninitialized >> >> This is useful for users who only care about definite uninitialized >> variable warnings. > I'm definitely in favor of having the ability for the user to be able to > fine tune the warnings they want. =A0However, I have some concerns. > > First, I'm not sure how reconcile the may vs must inconsistency. =A0We can > have an object which is used in a real statement in the IL, which we > currently would classify as must-be-uninitialized, even if the path > leading to the statement is unexecutable. =A0 =A0I guess I want to find > better ways to describe this kind of stuff in our documentation and > switch names There are three different kind of uninit warnings: 1) definitely uninitialized, and the use the variable dominates the exit -- this is the must be used uninitialized case 2) definitely uninitialized, but the use may not be executed at runtime; 3) Only initialized in some paths from entry to the use (the use may or may not be executed). Currently 2) and 3) uses the same warning message, which may be misleading. The proposed new option only controls 3). > > Second, I'm concerned about changing the default behaviour of > - -Wuninitialized. =A0I don't think we ever reached a consensus on that > issue last time we tried to hash through this stuff. =A0Maybe I missed > something, but it appears to me your patch makes -Wuninitialized only > warn about real uses and ignore uses in PHIs. No, the patch does not change the default behavior of -Wuninitialized wihch will turn on -Wmaybe-uninitialized as well. The only useful scenarios for the new option are: 1) -Wuninitialized -Wno-maybe-uninitialized 2) -Wuninitialized -Werror=3Duninitialized -Wno-error=3Dmaybe-uninitialized > > Given the lack of consensus (and I believe there will never be a > consensus), I believe we should keep -Wuninitialized behavior as-is and > use -Wno-maybe-uninitialized to override -Wuninitialized. Yes, that is this patch is supposed to do -- the attached test case is testing it. > > If we can come up with better switch name than -Wno-maybe-uninitialized, > that would be a good step as well. =A0However, I'm not offhand sure what > name to use given the issues surrounding may vs must be used uninitialize= d. Maybe-uninitialized matches case 3) -- different from case 2 which is actually 'maybe-used-uninitialized'. Thanks, David > > jeff > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNsGecAAoJEBRtltQi2kC7BugH/01X2ppdVUONq2fBzztxF+YR > Qn85yccwI45iizNG1dlmyZlYpATYcfTGwDkBYTjiVllhOJa64Ri6bIP3ErySPllk > OrSAbwFT96TK9/h1eGfVj45mZS3MO0Pa+sxp93noGnxIMWWOt+7LiyrfJEHHLaUK > rPhREXodzLnN0KpXTD8+RS2uzTV+YODAuiWQDkiyQ0XpjCw5w2ccc7dWnrzgvEn5 > 6x/baTqQxunV8t3/ezUlHiMcUNyMigXccFgIeRRsvMengY/reLxy7eg1i+vdeets > DyWR/Hg3HewLAQidL3SAJLLGuqTrNUZ0wswgqghqh9VllAFoUdKn0xk8GFt0wbk=3D > =3D4aA4 > -----END PGP SIGNATURE----- >