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
optimizer :-)
> 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
like this:
sub()
{
int i = 0;
int j = 0;
int k;
while ((i | j) == 0)
{
k = 10;
i = sub ();
}
return k;
}
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
assessment.
> this problem can be reduced to the stopping problem.
Precisely.
jeff
