Sounds like a good idea, but does -Werror=xxx work for this ? I tried cases with -Wstrict-aliasing, -Werror handling seems broken.
Thanks, David On Fri, Apr 22, 2011 at 1:52 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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----- >>> >> >