Hi,

On Mon, Nov 11 2019, Richard Biener wrote:
> On Fri, Nov 8, 2019 at 1:41 PM Martin Jambor <mjam...@suse.cz> wrote:
>>
>> Hi,
>>
>> this patch is an attempt to implement my idea from a previous thread
>> about moving -Wmaybe-uninitialized to -Wextra:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
>>
>> Specifically, it attempts to split -Wmaybe-uninitialized into those that
>> are about SRA DECLs and those which are not, and move to -Wextra only
>> the former ones.  The main idea is that false -Wmaybe-uninitialized
>> warings about values that are scalar in user's code are easy to silence
>> by initializing them to zero or something, as opposed to bits of
>> aggregates such as a value in std::optional which are not.  Therefore,
>> the warnings about user-scalars can remain in -Wall but warnings about
>> SRAed pieces should be moved to -Wextra.
>>
>> The patch is a bit bigger because of documentation (which I'll be happy
>> to improve based on your suggestions) and testsuite churn, but the main
>> bit is the following added test in warn_uninit function:
>>
>>   if (wc == OPT_Wmaybe_uninitialized
>>       && SSA_NAME_VAR (t)
>>       && DECL_ARTIFICIAL (SSA_NAME_VAR (t))
>>       && DECL_HAS_DEBUG_EXPR_P (SSA_NAME_VAR (t)))
>>     {
>>       if (warn_maybe_uninitialized_aggregates)
>>         wc = OPT_Wmaybe_uninitialized_aggregates;
>>       else
>>         return;
>>     }
>
> I wonder if this works in practice since the whole point of SRA is to
> have things copy propagated out (so the 't' with the SSA_NAME_VAR
> doesn't prevail or gets commoned with sth else).  Or is this about
> the default defs SRA creates itself to actually emit uninit warnings?

Yes, not warning for those default defs is the idea.  After all, only
when we warn about those DECLs (to which those default defs belong) the
user gets a warning that a bit which they cannot easily initialize on
their own is maybe uninitialized:

pr80635.C:12:13: warning: ‘c1.A::i’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

Martin

Reply via email to