Bug 22456

Hmm, the loop is empty therefore removed.

I don't know if we want to have a is used uninitilzed warning for an empty loop and dead code 
afterwards.

In a way this is just like:
void f(void)
{
  int i;
  if (i)
   i = 0;
}

Do we want a warning for that case or not?

I think it is acceptable to not show the warning in this case.  Does moving the
uninitialized warning above "fix" this bug?  If so, it is a dup of 18501.

I think this is a dup of bug 18501.

This will never be release-critical.

Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.

*** Bug 30542 has been marked as a duplicate of this bug. ***

*** Bug 30575 has been marked as a duplicate of this bug. ***

Is the code here or in comment #2 the same as in 30542 and 30575? It may be, but gcc users who don't know gcc internals (like me), can't easily see this, and missing warning (in those two bugs, not here) is quite a serious regression, which means one can expect more warnings to disappear.

*** Bug 30856 has been marked as a duplicate of this bug. ***

*** Bug 30856 has been marked as a duplicate of this bug. ***

Actually 22456 is CCP ignoring uninitialized vars on phi merging.  Testcase:

int foo(int f)
{
  int i;
  if (f)
    i = 5;
  return i;
}

CCP makes it return 5, so the set of i and the PHI becomes dead.  Before CCP
we have:

<bb 2>:
  if (f_2(D) != 0) goto <L0>; else goto <L1>;

<L0>:;
  i_4 = 5;

  # i_1 = PHI <i_3(D)(2), i_4(3)>
<L1>:;
  i_5 = i_1;

while CCP transforms it to

<bb 2>:
  if (f_2(D) != 0) goto <L0>; else goto <L1>;

<L0>:;
  i_4 = 5;

  # i_1 = PHI <i_3(D)(2), 5(3)>
<L1>:;
  i_5 = 5;

and the next DCE pass removes all but a return 5;

This can be fixed by making CCP not use undefined behavior.

Created attachment 13354 [details]
patch to preserve uninitialized PHI arguments in CCP

like so.  -O -Wall gives

t.i: In function 'foo':
t.i:3: warning: 'i' may be used uninitialized in this function

(In reply to comment #12)
> Created an attachment (id=13354) [edit]
> patch to preserve uninitialized PHI arguments in CCP
> 
> like so.  -O -Wall gives
> 
> t.i: In function 'foo':
> t.i:3: warning: 'i' may be used uninitialized in this function
> 

I don't think we want to do this, since it works fine in a lot of testcases that will get hindered. See http://gcc.gnu.org/ml/gcc/2005-11/msg00028.html

As far as I see this is a duplicate of PR18501.

Diego, I think this is caused by CCP silently merging UNDEFINED PHI nodes. We could group similar cases into PR18501, don't you think?

If not an exact duplicate, it's strongly related to 18501.  The code pattern is slightly different so it may be worth keeping around.  Adding a dependency on 18501.

Closing 4.1 branch.

Without optimization we build the following:

foo ()
{
  intD.0 iD.1591;

  # BLOCK 2
  # PRED: ENTRY (fallthru)
  [pr22456.c : 4] goto <bb 4>;
  # SUCC: 4 (fallthru)

  # BLOCK 3
  # PRED: 4 (true)
  [pr22456.c : 4] iD.1591_3 = iD.1591_1 + 1;
  # SUCC: 4 (fallthru)

  # BLOCK 4
  # PRED: 2 (fallthru) 3 (fallthru)
  # iD.1591_1 = PHI <iD.1591_2(D)(2), iD.1591_3(3)>
  [pr22456.c : 4] if (iD.1591_1 != 0)
    goto <bb 3>;
  else
    goto <bb 5>;
  # SUCC: 3 (true) 5 (false)

  # BLOCK 5
  # PRED: 4 (false)
  [pr22456.c : 5] return;
  # SUCC: EXIT

}

Because of the way the loop is represented, we generate a PHI node for the condition instead of a direct use. Since we do not warn about PHI nodes without optimization, then there is no warning.

With optimization the loop is completely removed since it doesn't do anything. Hence, there is no warning. I wasn't able to construct a testcase where the loop does anything useful (or the value of "i" is used after the loop) and we do not warn.

This doesn't have anything to do with CCP and it is not a duplicate of bug 18501.

Closed as INVALID. If anyone comes up with a testcase for this where the loop is not empty, open a new PR and add me to the CC.

There were couple of bugs with real C code where warnings are actually useful - see comment #2, and they were closed as a dup of this one. This one may or may not be important, but the warning did go for good, in valid cases (that is, in invalid but real program code). I would open a new entry as you say, but I don't think it makes sense - I already have opened one (closed as a dup), and I wasn't alone in that. I'll reopen #30575 because I can't reopen this one.

(In reply to comment #18)
> There were couple of bugs with real C code where warnings are actually useful -

Yes please. reopen what those that you feel are still valid and add me to the CC list.

(In reply to comment #19)
> (In reply to comment #18)
> > There were couple of bugs with real C code where warnings are actually useful -
> 
> Yes please. reopen what those that you feel are still valid and add me to the
> CC list.
> 

I have reviewed all of them already and reclassified. If you have more doubts, please read http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings and then ask.

*** Bug 40469 has been marked as a duplicate of this bug. ***

This bug is about not warning for an empty loop (the empty loop is removed and there is no warning). Since we don't care (enough to find a fix) about this case, this bug is considered INVALID.

Btw, since a couple of days the warning is back :-)

(In reply to comment #23)
> Btw, since a couple of days the warning is back :-)

That probably means a regression in the optimizers. Can you identify the revision?