[Bug middle-end/20968] Spurious "may be used uninitialized" warning

[Bug middle-end/20968] Spurious "may be used uninitialized" warning

[law at redhat dot com]

------- Comment #4 from law at redhat dot com  2005-11-08 17:47 -------
Just an interesting tidbit.

This testcase exposes a much more difficult/interesting long term problem. 
Namely, how should we handle uninitialized warnings for variables which are
exposed by optimization.

ie, in this case (and probably others), we have a local variable which has had
its address taken, which normally suppresses uninitialized warnings.  However,
inlining followed by our SSA optimizers proves that we don't need the address
of the local variable.  That in turn exposes the local variable and we want to
be able to warn about it if its uninitialized.

Similar issues probably exist for SRA optimizations.  Whee fun.

jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968

[Bug middle-end/20968] Spurious "may be used uninitialized" warning

[manu at gcc dot gnu dot org]

------- Comment #5 from manu at gcc dot gnu dot org  2007-08-22 17:14 -------
(In reply to comment #4)
> Just an interesting tidbit.
> 
> This testcase exposes a much more difficult/interesting long term problem. 
> Namely, how should we handle uninitialized warnings for variables which are
> exposed by optimization.

I think the problem reduces to "what we do when we are unsure?" Currently we
mostly warn except for CCP merging undefined values with constants and when the
address of the variable is passed to a function. If the body is not taken into
account (because it is not inlined) we assume that baz() initializes i. When
inlined, we are not sure anymore, so we warn. This will happen whenever more
optimisation turns the balance from "unsure but not warn" to "unsure but warn".
In the general case, I don't think this can be solved unless we always warn or
we always don't warn when unsure.

Therefore, the only thing we could do is handle the inlined version as well as
Andrew's testcase in comment #2.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968

[Bug middle-end/20968] spurious "may be used uninitialized" warning (conditional PHIs)

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2009-02-07 16:27 -------
This is just another case that would require conditional PHIs. I am not marking
it as a duplicate of bug 36550, because this case is harder than then typical:

if(q) p=1;
something()
if(q) use(p);

Therefore, it may be possible to fix bug 36550 and still not fix this.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |36550
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-02-07 16:27:01
               date|                            |
            Summary|Spurious "may be used       |spurious "may be used
                   |uninitialized" warning      |uninitialized" warning
                   |                            |(conditional PHIs)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968

[Bug middle-end/20968] spurious "may be used uninitialized" warning (conditional PHIs)

[manu at gcc dot gnu dot org]

------- Comment #7 from manu at gcc dot gnu dot org  2009-12-30 16:59 -------
*** Bug 42145 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |colin at reactos dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968

[Bug middle-end/20968] spurious "may be used uninitialized" warning (conditional PHIs)

[davidxl at gcc dot gnu dot org]

------- Comment #8 from davidxl at gcc dot gnu dot org  2010-04-21 00:27 -------
(In reply to comment #2)
> Note this is not fully a regression but really a progression.
> What is happening now is only partial optimizations is happen before the warning to happen.
> 
> >I was unable to reduce the test case further without making the warning
> >disappear.  In particular, removing the increment of v1->count makes the warning
> >disappear.
> This is because we would then jump thread he jump.
> 
> Again this is because we are emitting the warning too soon, I might be able to come up with a testcase 
> which shows that this is not really a regression but a progression in that we have warned in 3.4 and 
> 4.0:
> struct {int count;} *v1;
> int c;
> int k;
> 
> extern void baz(int);
> void foo(void)
> {
>     int i;
>     int r;
>     if (k == 4)
>     {
>         i = 1;
>         r = 1;
>     }
>     else
>         r = 0;
> 
>     if (!r)
>     {
>         if (!c)
>             return;
>         v1->count++;
>     }
>     if (!c)
>     {
>         baz(i);
>     }
> }
> 
> There is no different from the case above and the functions you gave below.
> 
> There has been some talking about moving where we warn about uninitialized variables but I feel that 
> you can get around this in your code.

To reproduce the problem -- -fno-tree-vrp  -fno-tree-dominator-opts
-fno-tree-ccp are needed. This 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968

[Bug middle-end/20968] Spurious "may be used uninitialized" warning

[James dot Juran at baesystems dot com]

------- Additional Comments From James dot Juran at baesystems dot com  2005-04-12 16:21 -------
Thanks for the info.  Your testcase does warn in all versions I tested.  We can
certainly initialize the variable in our code to get around this issue, but it
would be nice to not have to do this since the initialization is unnecessary. 
The original code is obviously more complicated, so manually inlining it as your
test case does is not really a viable option.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968

[Bug middle-end/20968] Spurious "may be used uninitialized" warning

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-12 14:49 -------
Note this is not fully a regression but really a progression.
What is happening now is only partial optimizations is happen before the warning to happen.

>I was unable to reduce the test case further without making the warning
>disappear.  In particular, removing the increment of v1->count makes the warning
>disappear.
This is because we would then jump thread he jump.

Again this is because we are emitting the warning too soon, I might be able to come up with a testcase 
which shows that this is not really a regression but a progression in that we have warned in 3.4 and 
4.0:
struct {int count;} *v1;
int c;
int k;

extern void baz(int);
void foo(void)
{
    int i;
    int r;
    if (k == 4)
    {
        i = 1;
        r = 1;
    }
    else
        r = 0;

    if (!r)
    {
        if (!c)
            return;
        v1->count++;
    }
    if (!c)
    {
        baz(i);
    }
}

There is no different from the case above and the functions you gave below.

There has been some talking about moving where we warn about uninitialized variables but I feel that 
you can get around this in your code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
            Summary|[4.0/4.1 Regression]        |Spurious "may be used
                   |Spurious "may be used       |uninitialized" warning
                   |uninitialized" warning      |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968