GCC Bugzilla Bug 18501

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

Created an attachment (id=7548) [edit]
test case, from tree-ssa-pre.c

Confirmed, CCP is removing the use of the uninitialized variable.

It has never worked on the tree-ssa branch.

This is not really fixable.

Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html

Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01314.html

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

Personally, I prefer misdiagnosing uninit-5.c as a possible uninitialized use,
rather than missing this pretty nasty case.

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.

Jeff has a much better approach to solving this. 
http://gcc.gnu.org/ml/gcc/2005-11/msg00032.html

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

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.

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

(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.

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

This is CCP related. (See "Problem 2: CCP assumes a value for uninitialized
variables" in http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings)

Closing 4.1 branch.

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

This defect has been open nearly 4 years.  Any hope of 
actually getting a fix commited?

(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.

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

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

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

note that gcc version 3.2.3 correctly reports this warning

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

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

Closing 4.2 branch.

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

We are not going to fix this.

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

(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.

(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.

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.

(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.

Huh.  Well then.

> 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.

(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.

GCC 4.3.4 is being released, adjusting target milestone.