PR 18501. Before I mark it WONTFIX.

[Diego Novillo <dnovillo at redhat dot com>]

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.