This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PR 18501. Before I mark it WONTFIX.



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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]