On Thu, Apr 21, 2011 at 7:43 PM, Xinliang David Li <davi...@google.com> wrote: > On Thu, Apr 21, 2011 at 10:21 AM, Jeff Law <l...@redhat.com> 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. Definitely uninitialized values that may be used >>> warning is not affected >>> 2) allow fine grain control on promotion of warnings to errors: >>> -Wno-error=maybe-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. However, I have some concerns. >> >> First, I'm not sure how reconcile the may vs must inconsistency. We 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. I 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. I don't think we ever reached a consensus on that >> issue last time we tried to hash through this stuff. Maybe 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=uninitialized -Wno-error=maybe-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. However, I'm not offhand sure what >> name to use given the issues surrounding may vs must be used uninitialized. > > Maybe-uninitialized matches case 3) -- different from case 2 which is > actually 'maybe-used-uninitialized'.
Other diagnostics use a level to indicate their noise level. So, why not do something like -Wuninitialized=N, with N from 1 to 3, covering all three cases. Also note that 1 and 2 are not really different as the function in question may be never executed, so 1 becomes 2 as well. Richard. > 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= >> =4aA4 >> -----END PGP SIGNATURE----- >> >