new option -Wno-maybe-uninitialized

[Xinliang David Li]

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.guenther@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 7:43 PM, Xinliang David Li <davidxl@google.com> wrote:
>> On Thu, Apr 21, 2011 at 10:21 AM, Jeff Law <law@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-----
>>>
>>
>