PR 18501. Before I mark it WONTFIX.

[Diego Novillo]

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.