Bug 22456 - [4.2/4.3/4.4 regression] (for empty loop) missing "is used uninitialized" warning
[4.2/4.3/4.4 regression] (for empty loop) missing "is used uninitialized" war...
Status: RESOLVED INVALID
Product: gcc
Classification: Unclassified
Component: middle-end
4.1.0
: P5 minor
: 4.2.5
Assigned To: Not yet assigned to anyone
: diagnostic, monitored
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2005-07-13 11:39 UTC by Volker Reichelt
Modified: 2009-07-13 06:44 UTC (History)
12 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-09-03 21:39:56


Attachments
patch to preserve uninitialized PHI arguments in CCP (1.65 KB, patch)
2007-04-11 22:24 UTC, Richard Biener
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Reichelt 2005-07-13 11:39:47 UTC
The following code used to trigger an "is used uninitialized" warning
if compiled with -Wall. Since a few days I'm not getting a warning anymore
on mainline (C and C++ frontend).

========================
void foo()
{
    int i;
    while (i) ++i;
}
========================
Comment 1 Andrew Pinski 2005-07-13 11:46:32 UTC
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?
Comment 2 Paolo Bonzini 2005-09-25 11:37:45 UTC
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.
Comment 3 Andrew Pinski 2005-10-12 00:21:16 UTC
I think this is a dup of bug 18501.
Comment 4 Mark Mitchell 2005-10-31 04:07:02 UTC
This will never be release-critical.
Comment 5 Mark Mitchell 2006-05-25 02:36:14 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 6 Andrew Pinski 2007-01-22 17:27:17 UTC
*** Bug 30542 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Pinski 2007-01-28 19:29:53 UTC
*** Bug 30575 has been marked as a duplicate of this bug. ***
Comment 8 Yevgen Muntyan 2007-01-28 20:15:44 UTC
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.
Comment 9 Andrew Pinski 2007-02-19 10:12:28 UTC
*** Bug 30856 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Pinski 2007-02-19 18:44:41 UTC
*** Bug 30856 has been marked as a duplicate of this bug. ***
Comment 11 Richard Biener 2007-04-11 22:17:29 UTC
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.

Comment 12 Richard Biener 2007-04-11 22:24:49 UTC
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
Comment 13 Manuel López-Ibáñez 2007-08-15 15:02:11 UTC
(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.
Comment 14 Manuel López-Ibáñez 2007-08-15 15:05:17 UTC
Diego, I think this is caused by CCP silently merging UNDEFINED PHI nodes. We could group similar cases into PR18501, don't you think?
Comment 15 Diego Novillo 2007-08-16 15:22:22 UTC
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.
Comment 16 Joseph S. Myers 2008-07-04 19:57:57 UTC
Closing 4.1 branch.
Comment 17 Manuel López-Ibáñez 2009-02-07 15:35:16 UTC
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.
Comment 18 Yevgen Muntyan 2009-02-07 20:35:05 UTC
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.
Comment 19 Manuel López-Ibáñez 2009-02-07 20:58:56 UTC
(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.

Comment 20 Manuel López-Ibáñez 2009-02-07 21:33:08 UTC
(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.
Comment 21 Richard Biener 2009-06-17 11:47:35 UTC
*** Bug 40469 has been marked as a duplicate of this bug. ***
Comment 22 Manuel López-Ibáñez 2009-06-17 12:00:23 UTC
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.
Comment 23 Volker Reichelt 2009-07-12 21:57:44 UTC
Btw, since a couple of days the warning is back :-)
Comment 24 Manuel López-Ibáñez 2009-07-13 06:44:39 UTC
(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?