Bug 18501 - [4.7/4.8/4.9/4.10 Regression] Missing 'used uninitialized' warning (CCP)
[4.7/4.8/4.9/4.10 Regression] Missing 'used uninitialized' warning (CCP)
Status: REOPENED
Product: gcc
Classification: Unclassified
Component: tree-optimization
4.0.0
: P5 minor
: 4.7.4
Assigned To: Not yet assigned to anyone
: diagnostic
: 30542 30575 30856 33327 36814 37148 38945 39113 40469 42724 42884 45493 46684 46853 47623 48414 48643 49971 56972 57629 58323 58890 59225 60444 (view as bug list)
Depends on:
Blocks: Wuninitialized 30542 30856
  Show dependency treegraph
 
Reported: 2004-11-15 13:35 UTC by Nathan Sidwell
Modified: 2014-03-13 18:03 UTC (History)
36 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-08-18 15:41:48


Attachments
test case, from tree-ssa-pre.c (200 bytes, text/plain)
2004-11-15 13:36 UTC, Nathan Sidwell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Sidwell 2004-11-15 13:35:42 UTC
The attached testcase has an uninitialized variable, it is not
diagnosed with -O2 -W -Wall.  Gcc 3.2 says,

uninit.i: In function `bitmap_print_value_set':
uninit.i:8: warning: `first' might be used uninitialized in this function

this is a regression
Comment 1 Nathan Sidwell 2004-11-15 13:36:21 UTC
Created attachment 7548 [details]
test case, from tree-ssa-pre.c
Comment 2 Andrew Pinski 2004-11-15 13:50:25 UTC
Confirmed, CCP is removing the use of the uninitialized variable.
Comment 3 Andrew Pinski 2004-12-05 04:04:46 UTC
It has never worked on the tree-ssa branch.
Comment 4 Diego Novillo 2004-12-16 20:42:18 UTC
This is not really fixable.

Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html
Comment 5 Diego Novillo 2004-12-17 22:21:13 UTC
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01314.html
Comment 6 Diego Novillo 2005-05-11 02:25:19 UTC
Re-opening.  A re-organization of the tree optimizers is causing us to
misdiagnose this test case once again.  I am going to work on a better warning
implementation that doesn't get confused so easily.

See http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00955.html
Comment 7 Paolo Bonzini 2005-09-25 11:37:42 UTC
Personally, I prefer misdiagnosing uninit-5.c as a possible uninitialized use,
rather than missing this pretty nasty case.
Comment 8 Mark Mitchell 2005-10-31 01:41:36 UTC
Downgrading to P5; this would never be release-critical.

Missing this warning does seem a shame though.   And, I think that people who want this warning would rather have false positives (which can be avoid with perhaps-unncessary optimizations) than false negatives, which can result in bugs of exactly the kind they're trying to catch.  I'd suggest that we consider moving this check very early in the optimization chain so that we get more consistent results across platforms, more consistent results across optimization levels, and more predictability from release to release.
Comment 9 Diego Novillo 2005-11-01 18:29:17 UTC
Jeff has a much better approach to solving this.  http://gcc.gnu.org/ml/gcc/2005-11/msg00032.html
Comment 10 Jeffrey A. Law 2005-11-01 18:50:14 UTC
Subject: Re:  [4.1 Regression] Missing 'used
	unintialized' warning

On Tue, 2005-11-01 at 18:29 +0000, dnovillo at gcc dot gnu dot org
wrote:
> 
> ------- Comment #9 from dnovillo at gcc dot gnu dot org  2005-11-01 18:29 -------
> 
> Jeff has a much better approach to solving this. 
> http://gcc.gnu.org/ml/gcc/2005-11/msg00032.html
I'd rather you not assign it to me just yet -- while I think my approach
is better, I don't think we have a consensus that it's what we're going
to do yet :-)

jeff


Comment 11 Diego Novillo 2005-11-01 18:56:43 UTC
Subject: Re:  [4.1 Regression] Missing 'used unintialized' warning

On Tuesday 01 November 2005 13:50, law at redhat dot com wrote:

> I'd rather you not assign it to me just yet -- while I think my approach
> is better, I don't think we have a consensus that it's what we're going
> to do yet :-)
>
Don't worry, I haven't assigned it :)  I just added a pointer to the thread 
and added you to the CC list.
Comment 12 Mark Mitchell 2006-05-25 02:35:37 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 13 Manuel López-Ibáñez 2007-03-06 11:41:42 UTC
(In reply to comment #4)
> This is not really fixable.
> 
> Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html

I am really ignorant on this CCP optimisaton but I am willing to learn. I guess that we merge UNDEFINED and 0 because we can assume that undefined is anything. I am not so sure that is OK in this particular case. However, even in that case, we should warn just at that moment, since we are already using an UNDEFINED value, aren't we?

My point is that this testcase is fundamentally different from:
  int x;
  if (f())
    x = 3;
  return x;

where f() is optimised away because it is always true. Some users may not want to get warnings for the latter case, but any reasonable user wants to get a warning for this PR.

Please, correct me when I am wrong. Thanks.
Comment 14 Andrew Pinski 2007-09-06 22:30:28 UTC
*** Bug 33327 has been marked as a duplicate of this bug. ***
Comment 15 Manuel López-Ibáñez 2008-01-21 16:01:56 UTC
This is CCP related. (See "Problem 2: CCP assumes a value for uninitialized variables" in http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings)
Comment 16 Joseph S. Myers 2008-07-04 16:46:36 UTC
Closing 4.1 branch.
Comment 17 Manuel López-Ibáñez 2008-08-18 13:46:02 UTC
*** Bug 37148 has been marked as a duplicate of this bug. ***
Comment 18 thutt 2008-08-18 13:55:46 UTC
This defect has been open nearly 4 years.  Any hope of 
actually getting a fix commited?
Comment 19 Manuel López-Ibáñez 2008-08-18 14:09:10 UTC
(In reply to comment #18)
> This defect has been open nearly 4 years.  Any hope of 
> actually getting a fix commited?

To be bluntly honest. No, do not expect a fix in the near/medium future. Not for GCC 4.4 for sure.

CCP relies on this behaviour to optimize code, so we cannot disable it. Moving passes around (warning before CCP, warning before DCE) would just generate different false positives/negatives. This is a complex issue:

http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#problem_ccp

Plus, no one is working or planning to work on this at the moment AFAIK.
Comment 20 Manuel López-Ibáñez 2008-08-18 18:56:30 UTC
*** Bug 36814 has been marked as a duplicate of this bug. ***
Comment 21 Andrew Pinski 2009-01-26 19:27:15 UTC
*** Bug 38945 has been marked as a duplicate of this bug. ***
Comment 22 Andrew Pinski 2009-02-05 21:57:12 UTC
*** Bug 39113 has been marked as a duplicate of this bug. ***
Comment 23 David Hill 2009-02-05 22:44:17 UTC
note that gcc version 3.2.3 correctly reports this warning
Comment 24 Manuel López-Ibáñez 2009-02-07 21:15:06 UTC
*** Bug 30575 has been marked as a duplicate of this bug. ***
Comment 25 Manuel López-Ibáñez 2009-02-07 21:29:45 UTC
*** Bug 30856 has been marked as a duplicate of this bug. ***
Comment 26 Joseph S. Myers 2009-03-31 16:41:35 UTC
Closing 4.2 branch.
Comment 27 Manuel López-Ibáñez 2009-06-17 12:03:25 UTC
*** Bug 40469 has been marked as a duplicate of this bug. ***
Comment 28 Richard Biener 2009-06-17 12:06:00 UTC
We are not going to fix this.
Comment 29 Richard Biener 2009-06-17 12:06:56 UTC
*** Bug 30542 has been marked as a duplicate of this bug. ***
Comment 30 Manuel López-Ibáñez 2009-06-17 12:09:21 UTC
(In reply to comment #28)
> We are not going to fix this.
> 

Why? There are many ways to alleviate this. Doing some warnings in the front-ends, such LLVM does is one. Or propagate some "uninitialized" bit, that can checked later. Or something that hasn't invented yet. It is clear that other compilers can get this right, so GCC could, if someone had the time and interest.
Comment 31 Manuel López-Ibáñez 2009-06-17 12:17:57 UTC
(In reply to comment #30)
> (In reply to comment #28)
> > We are not going to fix this.
> > 
> 
> Why? There are many ways to alleviate this. Doing some warnings in the
> front-ends, such LLVM does is one. Or propagate some "uninitialized" bit, that
> can checked later. Or something that hasn't invented yet. It is clear that
> other compilers can get this right, so GCC could, if someone had the time and
> interest.

BTW, in my review of Wuninitialized problems, this is problem number 1 of missing warnings, as evidenced by the number of duplicates. So even alleviating this in simple cases would be a major improvement.

Comment 32 Richard Biener 2009-06-17 12:59:33 UTC
We can only fix it with the chance of raising more spurious warnings.  One
reason why we run the "may be used uninitialized" pass very late.
Comment 33 Manuel López-Ibáñez 2009-06-17 13:25:36 UTC
(In reply to comment #32)
> We can only fix it with the chance of raising more spurious warnings.  One
> reason why we run the "may be used uninitialized" pass very late.

The solution of moving the passes around has been discarded long ago. There are other possible solutions.

Nonetheless, every change that warns were we previously didn't may rise more spurious warnings, per the Halting problem. In fact, your patch to enable Wuninitialized at -O0 did certainly introduce many spurious warnings. Are you going to revert it? Making use of alias info to detect unitialized uses will introduce spurious warnings, are you going to close PR 19430 and similar?

If so, feel free to go through http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#current and close all items as WONTFIX. You may all well directly close all bugs listed in PR 24639 that report a missing warning, since implementing the warning will almost certainly lead to spurious warning.

The goal is to find a balance. Per Chris Lattner account, LLVM is able to detect simple cases of this PR without generating spurious warnings. So it can definitely be done.

I think this PR should be kept open in case someone decides to improve the situation a bit. Please reopen.
Comment 34 Richard Biener 2009-06-17 13:55:00 UTC
Huh.  Well then.
Comment 35 Richard Biener 2009-06-17 13:56:22 UTC
> The solution of moving the passes around has been discarded long ago. There are
> other possible solutions.

so, what are these?  Once we removed the uninitialized use (CCP) we cannot
recover the information.
Comment 36 Manuel López-Ibáñez 2009-06-23 00:12:04 UTC
(In reply to comment #35)
> 
> so, what are these?  Once we removed the uninitialized use (CCP) we cannot
> recover the information.
 
We usually do not remove the uninitialized use but assume a value for the variable and propagate it. The standard testcase

  int x;
  if (f())
    x = 3;
  return x;

The code is simplified to return (3), but perhaps we could mark this constant as being possibly uninitialized. A later pass can report it if it never gets removed. Or perhaps we could do some basic (and fast) CCP in the front-end to detect may-be-uninitialized uses.

In http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#current I give more ideas. That no one has found a fix does not mean that a fix is not possible. Users are going to keep reporting this, and we have many much older bugs still open. It took 8 years to fix PR179.
Comment 37 Richard Biener 2009-08-04 12:26:08 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 38 Manuel López-Ibáñez 2010-01-13 16:33:38 UTC
*** Bug 42724 has been marked as a duplicate of this bug. ***
Comment 39 Richard Biener 2010-05-22 18:10:07 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 40 Manuel López-Ibáñez 2010-09-02 22:50:48 UTC
*** Bug 45493 has been marked as a duplicate of this bug. ***
Comment 41 Manuel López-Ibáñez 2010-09-02 23:10:03 UTC
*** Bug 42884 has been marked as a duplicate of this bug. ***
Comment 42 Manuel López-Ibáñez 2010-12-09 14:45:18 UTC
*** Bug 46853 has been marked as a duplicate of this bug. ***
Comment 43 Tom St Denis 2010-12-09 15:25:25 UTC
Maybe it's high time someone address this shortcoming as opposed to adding additional language front ends.  If you can't even get the core ones right...

Just saying...
Comment 44 Jonathan Wakely 2010-12-09 16:06:28 UTC
(In reply to comment #43)
> Maybe it's high time someone address this shortcoming as opposed to adding
> additional language front ends.  If you can't even get the core ones right...

Generally the people who add front-ends aren't the people working on the middle-end and optimisers, so work on one doesn't take resources away from the other.

Feel free to pay someone to fix it if this is important to you. Just sayin'
Comment 45 Manuel López-Ibáñez 2010-12-09 16:34:46 UTC
(In reply to comment #44)
> (In reply to comment #43)
> > Maybe it's high time someone address this shortcoming as opposed to adding
> > additional language front ends.  If you can't even get the core ones right...
> 
> Generally the people who add front-ends aren't the people working on the
> middle-end and optimisers, so work on one doesn't take resources away from the
> other.
> 

Moreover, the people that add new FEs are not the same people working on the C/C++ FEs. 

Anyway, in the comments above you can find the reasons why this is difficult, how Clang has solved it (or so they say, I haven't seen a comparison over many different testcases), and why you should not expect a fix in the medium term.
Comment 46 Tom St Denis 2010-12-09 17:03:37 UTC
(In reply to comment #44)
> (In reply to comment #43)
> > Maybe it's high time someone address this shortcoming as opposed to adding
> > additional language front ends.  If you can't even get the core ones right...
> 
> Generally the people who add front-ends aren't the people working on the
> middle-end and optimisers, so work on one doesn't take resources away from the
> other.

It still adds work to the project as a whole and serves as a distraction for new people who have the time to contribute.

> Feel free to pay someone to fix it if this is important to you. Just sayin'

If fixing known bugs is not a priority then of what value is this project other than being free?  I thought the whole point was to also be correct.  Granted this isn't a show-stopper as far as bugs go, but the laissez-faire "if you hate it fix it yourself" trend in OSS is really annoying.

When I ran my own OSS projects I never told the users "nyah nyah fix it yourself!"  When I ran out of time to work on the OSS projects I gave them up, but so long as I called myself a maintainer I addressed issues as best as I could.

I'd almost rather they leave it as WONTFIX then just leaving it open.  I'd also be happier if they documented this class of SSA fail in the man page so people don't walk into it [as I and others have].
Comment 47 Manuel López-Ibáñez 2010-12-09 18:06:05 UTC
(In reply to comment #46)
> It still adds work to the project as a whole and serves as a distraction for
> new people who have the time to contribute.
>

The same could be said of any feature or bugfix. It depends on your priorities and viewpoint. In fact, the way GCC development works, making a new feature work (like a new FE) may provide the motivation for someone to fix an old bug.

> I'd almost rather they leave it as WONTFIX then just leaving it open.

How is that a solution? People will keep reporting it. As said above, it took more than 8 years to solve some bugs, but someone came around and fixed them. There are much older bugs than this one that may get fixed in the next couple of releases.

WONTFIX means GCC devs don't want a fix. This is not the case here. There are even ideas above about how to fix this. It is just that there is no enough motivation for anyone to deal with the probably huge amount of work it requires.
Comment 48 Hans-Peter Nilsson 2010-12-10 00:08:40 UTC
(In reply to comment #47)
> WONTFIX means GCC devs don't want a fix.

Not quite, and saying it that way, sends the wrong message.  It's more like "are not going to put resources (of their own) into fixing it".
Comment 49 Jonathan Wakely 2010-12-10 01:24:19 UTC
(In reply to comment #46)
> 
> If fixing known bugs is not a priority then of what value is this project other
> than being free?  I thought the whole point was to also be correct.  Granted
> this isn't a show-stopper as far as bugs go, but the laissez-faire "if you hate
> it fix it yourself" trend in OSS is really annoying.

So is the trend of users who leave snarky "just saying" comments claiming things "can't be done right." GCC is not a static analysis tool, it will never be as good at some things as some other tools - that doesn't make it useless or incorrect.  Imperfect, yes, and noone disputes that.

Fixing bugs is a priority, just look on the mailing lists to see how many are fixed.  Search for Manu's comments to see how hard he works (in his own time) trying to fix longstanding bugs such as this, or at least try to improve the situation slightly, or just identify duplicate reports.

But not all bugs are equal. To generalise from the fact that one particularly difficult bug hasn't been fixed to claim that fixing known bugs is not a priority, and to question the value of the entire project, just makes you sound ridiculous.
Comment 50 Manuel López-Ibáñez 2011-02-06 20:25:13 UTC
*** Bug 47623 has been marked as a duplicate of this bug. ***
Comment 51 Manuel López-Ibáñez 2011-02-06 20:48:38 UTC
BTW, anyone interested in fixing this may want to take a look at the newest proposal for improving Wuninitialized in Clang:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013170.html

They specifically mention the issues of GCC's implementation and how they plan to address them. Nevertheless, there are several problems for implementing Clang's approach in GCC. First, they prefer to have false positives (a false warning) than false negatives (a missed correct warning), whereas GCC tries as hard as possible to not warn when it shouldn't.  Second, their proposal makes use of the static analysis checker build into clang, which GCC does not have (and probably never will) in its front-ends.
Comment 52 Richard Biener 2011-06-27 12:12:29 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 53 Manuel López-Ibáñez 2011-06-27 13:06:09 UTC
(In reply to comment #52)
> 4.3 branch is being closed, moving to 4.4.7 target.

Richard, I would suggest to remove the regression markers. This is a regression since 4.0 that it is unlikely to be fixed in the near future. Hence, not really worth to track as a regression. One less bug to handle by the release managers.
Comment 54 Manuel López-Ibáñez 2011-08-04 08:41:02 UTC
*** Bug 49971 has been marked as a duplicate of this bug. ***
Comment 55 Jakub Jelinek 2012-03-13 12:45:16 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 56 Manuel López-Ibáñez 2012-10-24 22:05:41 UTC
*** Bug 48414 has been marked as a duplicate of this bug. ***
Comment 57 Manuel López-Ibáñez 2012-10-24 22:16:09 UTC
BTW, Clang has decided to implement this in the FE for simple cases.

Quoting: http://clang.llvm.org/docs/ReleaseNotes.html

-Wuninitialized has been taught to recognise uninitialized uses which always occur when an explicitly-written non-constant condition is either true or false. For example:

int f(bool b) {
  int n;
  if (b)
    n = 1;
  return n;
}

sometimes-uninit.cpp:3:7: warning: variable 'n' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
  if (b)
      ^
sometimes-uninit.cpp:5:10: note: uninitialized use occurs here
  return n;
         ^
sometimes-uninit.cpp:3:3: note: remove the 'if' if its condition is always true
  if (b)
  ^~~~~~
sometimes-uninit.cpp:2:8: note: initialize the variable 'n' to silence this warning
  int n;
       ^
        = 0
Comment 58 Manuel López-Ibáñez 2012-10-24 23:52:08 UTC
*** Bug 46684 has been marked as a duplicate of this bug. ***
Comment 59 Manuel López-Ibáñez 2012-10-24 23:57:21 UTC
*** Bug 48643 has been marked as a duplicate of this bug. ***
Comment 60 Jakub Jelinek 2013-04-12 15:15:48 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 61 Manuel López-Ibáñez 2013-04-15 18:46:59 UTC
*** Bug 56972 has been marked as a duplicate of this bug. ***
Comment 62 Manuel López-Ibáñez 2013-06-16 15:23:46 UTC
*** Bug 57629 has been marked as a duplicate of this bug. ***
Comment 63 Manuel López-Ibáñez 2013-07-09 09:20:56 UTC
*** Bug 57856 has been marked as a duplicate of this bug. ***
Comment 64 Chen Gang 2013-07-10 00:22:44 UTC
(In reply to Manuel López-Ibáñez)
> 

Firstly, thank you very much for keeping tracing this bug almost 10 years, and provided your suggestions as much as possible.

What you have done is valuable to developers (at least to me); at least the developers can easily and quickly know about this gcc common issue in time, and they will notice about it and think another ways to process this issue in their own projects (e.g. firstly compile with -O0 to see warnings).

And sorry for I am not quite familiar with gcc compilier implementation, so at least now, I can not fix this issue, although of cause this issue really can be fixed (just as what you said).

Thanks again.
Comment 65 Manuel López-Ibáñez 2013-09-07 17:53:17 UTC
*** Bug 58323 has been marked as a duplicate of this bug. ***
Comment 66 Manuel López-Ibáñez 2013-10-27 01:15:20 UTC
*** Bug 58890 has been marked as a duplicate of this bug. ***
Comment 67 Manuel López-Ibáñez 2013-11-21 03:43:53 UTC
*** Bug 59225 has been marked as a duplicate of this bug. ***
Comment 68 Manuel López-Ibáñez 2013-11-21 03:55:51 UTC
(In reply to Manuel López-Ibáñez from comment #67)
> *** Bug 59225 has been marked as a duplicate of this bug. ***

PR 59225 gave me an idea. Wouldn't it be possible to keep a PHI node with just two operands, the constant and the undefined value? If further optimizations remove the undefined block as unexecutable, then the undefined operand will go away. Perhaps the problem is that other optimizations do not treat PHI<1,(D)> as simply 1 and this will result in worse code, although VRP seems to work just fine with PHI<1,2,(D)>.

Richard, do you see it feasible?
Comment 69 Jackie Rosen 2014-02-16 13:12:31 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
Comment 70 Manuel López-Ibáñez 2014-03-13 17:59:58 UTC
*** Bug 60444 has been marked as a duplicate of this bug. ***
Comment 71 Tom St Denis 2014-03-13 18:03:19 UTC
Hey guys, this year will be the 10 year anniversary of this bug.  We should order cake!