This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
PR 18501. Before I mark it WONTFIX.
- From: Diego Novillo <dnovillo at redhat dot com>
- To: gcc at gcc dot gnu dot org, Nathan Sidwell <nathan at codesourcery dot com>
- Date: Thu, 16 Dec 2004 15:39:25 -0500
- Subject: PR 18501. Before I mark it WONTFIX.
- Organization: Red Hat Canada
Nathan filed this PR. With GCC 3.2 we used to give an uninitialized
warning but we don't anymore:
void
bitmap_print_value_set (void)
{
unsigned first;
for (; bmp_iter_set (); )
{
if (!first)
something ();
first = 0;
}
}
which looks like this right before CCP (notice that the only assignment
to 'first' has already been removed by DCE):
{
goto <bb 4> (<L3>);
<L0>:;
if (first_1 == 0) goto <L1>; else goto <L2>;
<L1>:;
something ();
<L2>:;
# first_1 = PHI <first_2(0), 0(3)>;
<L3>:;
D.1474_3 = bmp_iter_set ();
if (D.1474_3 != 0) goto <L0>; else goto <L4>;
<L4>:;
return;
}
When CCP visits the PHI node for first_1, it merges the values of
first_2 (UNDEFINED since it's a default definition of a local variable)
with 0. Since we are allowed to assume whatever value is convenient, we
go ahead with 0 and fold 'if (first_1 == 0)' into 'if (1)'. That leaves
us with:
{
goto <bb 3> (<L3>);
<L1>:;
something ();
<L2>:;
# first_1 = PHI <first_2(0), 0(2)>;
<L3>:;
D.1474_3 = bmp_iter_set ();
if (D.1474_3 != 0) goto <L1>; else goto <L4>;
<L4>:;
return;
}
So, the next DCE run removes first_1's PHI node leaving nothing to
pass_late_warn_uninitialized to warn about.
I've tried a couple of different approaches, but this is ultimately
pretty annoying to deal with. If we schedule
pass_late_warn_uninitialized before the final DCE run, we get this case
right because we give it a chance to run before 'first_1' disappears.
However, this also means that we will get spurious warnings in cases
like testsuite/gcc.dg/uninit-5.c (which was mis-diagnosed by GCC 3.2 for
the exact same reason that GCC 4.0 mis-diagnoses this case, btw).
So, "rock, meet hard place". I also tried propagating an attribute in
CCP for when we merge with a default definition. It's the exact same
problem. We are diagnosing too early for some cases.
It will boil down to what we want to prioritize: false positives or
false negatives. I'm almost tempted to prioritize false positives (ie,
give a warning), but that would break uninit-5.c which seems to be a
common case:
if(cond)
x = 1;
foo();
if(cond)
use(x);
Thoughts?
Diego.