This is the mail archive of the
mailing list for the GCC project.
Re: -Wuninitialized issues
- From: Jeffrey A Law <law at redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 01 Nov 2005 11:17:52 -0700
- Subject: Re: -Wuninitialized issues
- References: <4365CA5E.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- Reply-to: law at redhat dot com
On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> To prevent losing location information for the warning, I had modified the
> propagation engine to warn as it folded the expression away.
Possibly a useful thing to have, but I don't think we want to put
the burden of detecting uninitialized variables onto each
> So, as we fold 'if (first_1 == 0)' into 'if (1)', the patch emits the
> warning about the possibly uninitialized value of 'first'. My approach
> improved precision of the warning because we are able to indicate exactly
> what statement is doing the uninitialized reference.
Instead of warning about the uninitialized reference here, I think
we want to be conditionally warning about the fact that the conditional
is always taken (or not-taken).
> However, there are two huge problems with the approach: (1) it is
> intrusive. Passes are required to keep track of their actions, in this
> case, CCP would inform the propagation engine that it had called the merge
> operator with an uninitialized value.
Yup, which I really don't like.
> (2) it introduces false positives:
I think false positives are inevitable if we attempt to solve the
problems Mark is complaining about. That's part of the reason why
I think this needs to be switch controlled.
Your example is probably derived from C code which looks something
int i = 0;
int j = 0;
while ((i | j) == 0)
k = 10;
i = sub ();
And my proposal will generate a warning like this:
yy.c:5: warning: 'k' may have been used uninitialized in this function,
but was later optimized away or proven always uninitialized
Clearly the message could be better, but it's easy to see how this
warning distinguishes itself from the "blah may be used uninitialized in
this function" warning we give in other cases. We clearly state that
it appeared to be used uninitialized, but optimizations changed that
> this problem can be reduced to the stopping problem.