This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Should -Wjump-misses-init be in -Wall?
- From: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Paolo Bonzini <bonzini at gnu dot org>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Joe Buck <Joe dot Buck at synopsys dot com>, Robert Dewar <dewar at adacore dot com>, "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>, Jeff Law <law at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, James Dennett <james dot dennett at gmail dot com>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 25 Jun 2009 22:17:33 +0200
- Subject: Re: Should -Wjump-misses-init be in -Wall?
- References: <18738acb0906200650o13cdfe6dv471d4277d657d4f8@mail.gmail.com> <4A4033D0.9080209@adacore.com> <20090623054326.GA32450@bubble.grove.modra.org> <206fcf960906230035j75223bbdq4412af0b54f15730@mail.gmail.com> <20090623161223.GA22175@synopsys.com> <206fcf960906230932u383392a5v8a87dd5e1a408f62@mail.gmail.com> <4A41068B.1080203@gnu.org> <m3zlby94iw.fsf@google.com> <6c33472e0906251111t22be1174oee4abe977eec4e80@mail.gmail.com> <84fc9c000906251218ib8f1e4fj6336a88923927ef@mail.gmail.com>
2009/6/25 Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Jun 25, 2009 at 8:11 PM, Manuel
> López-Ibáñez<lopezibanez@gmail.com> wrote:
>> 2009/6/23 Ian Lance Taylor <iant@google.com>:
>>> Paolo Bonzini <bonzini@gnu.org> writes:
>>>
>>>> I don't think this warning can report anything that -Wuninitialized
>>>> cannot report, so it should go in -Wc++-compat only.
>>>
>>> For the record, it can, as in when compiling this case without
>>> optimization. ?This is not a strong example by any means.
>>
>> This is a part of SSA that I don't understand completely. We create a
>> var_decl for i in the following assignment:
>>
>> D.1606_1 = i;
>>
>> because i is loaded from memory. But then, because there is no alias
>> info, there are no vuse/vdef operators for this statement. So we
>
> The only reason there is no VUSE/VDEF at -O0 is that we never need
> it, so we omit it for efficiency reasons. ?We have enough information
> at -O0 to add them should we need them.
My question was more like: Can we actually tell other way that this
var_decl is an use of uninitialized variable?
I think this is related to PR19430.
Cheers,
Manuel.