This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: new option -Wno-maybe-uninitialized
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-----
>>
>