[Bug c/36296] New: wrong warning about potential uninitialized variable

[Bug c/36296] New: wrong warning about potential uninitialized variable

[zimmerma+gcc at loria dot fr]

When compiling mpfr-2.3.1 with gcc-4.3, one gets the following warning
(among others):
{{{
lngamma.c: In function 'mpfr_lngamma_aux':
lngamma.c:160: warning: 'B' may be used uninitialized in this function
}}}
However, looking at the code shows that this variable cannot be used
uninitialized:
* a variable Bm is initialized to zero
* if Bm=0, B is initialized using an auxiliary function, and Bm is set to 2
  (this code is in a do { ... } while loop, thus is always executed)


-- 
           Summary: wrong warning about potential uninitialized variable
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zimmerma+gcc at loria dot fr
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-22 08:22 -------
It is most likely the case, that we have to use predicated PHI nodes to detect
that the variable is no unitialized.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #2 from vincent at vinc17 dot org  2008-05-22 08:34 -------
The severity should probably be changed to enhancement because gcc behaves as
documented (well, almost).

What can be done IMHO is:
1. Split the -Wuninitialized into two different warnings: one for which gcc
knows that the variable is uninitialized and one for which it cannot decide.
-Wuninitialized currently does both.
2. Provide an extension so that the user can tell gcc not to emit a warning for
some particular variable. This would sometimes be better than adding a dummy
initialization (which has its own drawbacks).

In the mean time, make the documentation better concerning -Wuninitialized:
change the first sentence "Warn if an automatic variable is used without first
being initialized [...]" to "Warn if an automatic variable *may be* used
without first being initialized" (though the behavior is detailed later).


-- 

vincent at vinc17 dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent at vinc17 dot org


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-22 10:21 -------
A way to tell gcc a variable is not uninitialized is to perform
self-initialization like

 int i = i;

this will cause no code generation but inhibits the warning.  Other compilers
may warn about this construct of course.


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #4 from vincent at vinc17 dot org  2008-05-22 11:01 -------
(In reply to comment #3)
> A way to tell gcc a variable is not uninitialized is to perform
> self-initialization like
> 
>  int i = i;

This doesn't seem to be valid C code.

> this will cause no code generation but inhibits the warning.  Other compilers
> may warn about this construct of course.

Or worse, generate non-working code.


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #5 from vincent at vinc17 dot org  2008-05-22 11:23 -------
BTW, the i = i trick, which is guaranteed to be valid and no-op only *after* i
has been initialized doesn't avoid the warning in such a case. I don't know if
this would be a good feature (the main drawback I can see would be to miss
warnings when this is a result of macro expansion). For instance:

#include <assert.h>
int foo (int x)
{
  int y;
  assert (x == 0 || x == 1);
  if (x == 0)
    y = 1;
  else if (x == 1)
    y = 2;
  y = y;  /* to tell the compiler that y has been initialized */
  return y;
}


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-05-28 07:31 -------
(In reply to comment #5)
> BTW, the i = i trick

it only works in the initializer and not as a statement after the fact.

That is: 
#include <assert.h>
int foo (int x)
{
  int y = y;
  assert (x == 0 || x == 1);
  if (x == 0)
    y = 1;
  else if (x == 1)
    y = 2;
  return y;
}

Will work, also with the jump threading, GCC should be able to figure out that
y is always inlined (except when -DNDEBUG is used).

-- Pinski


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #7 from vincent at vinc17 dot org  2008-05-28 08:18 -------
(In reply to comment #6)
> (In reply to comment #5)
> > BTW, the i = i trick
> 
> it only works in the initializer and not as a statement after the fact.

But in such a case, as i is not initialized yet, this may be undefined behavior
with some C implementations.


-- 


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[manu at gcc dot gnu dot org]

------- Comment #8 from manu at gcc dot gnu dot org  2008-08-18 17:24 -------
Please provide a preprocessed reduced testcase as similar to the original as
possible. 

I think this is not only predicated PHI but our representation of loops may
also have something to do.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
OtherBugsDependingO|                            |24639
              nThis|                            |
             Status|UNCONFIRMED                 |WAITING


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

[Bug middle-end/36296] wrong warning about potential uninitialized variable

[vincent at vinc17 dot org]

------- Comment #9 from vincent at vinc17 dot org  2008-08-18 22:58 -------
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible. 

Here's a similar testcase.

$ cat tst.c
void *foo (void);
void bar (void *);

void f (void)
{
  int init = 0;
  void *p;

  while (1)
    {
      if (init == 0)
        {
          p = foo ();
          init = 2;
        }
      bar (p);
    }
}

$ gcc -Wall -O2 tst.c -c
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function

This is quite strange: if I replace the value 2 by 1 or if I replace foo() by
0, the warning is no longer displayed.

Note: in the reality (in MPFR), the variable I called init here is the size of
the array (0 when the array hasn't been allocated yet).


-- 


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation)

[manu at gcc dot gnu dot org]

------- Comment #10 from manu at gcc dot gnu dot org  2008-08-18 23:38 -------
(In reply to comment #9)
> (In reply to comment #8)
> > Please provide a preprocessed reduced testcase as similar to the original as
> > possible. 
> 
> Here's a similar testcase.

Thanks.

This is the optimized SSA dump:

f ()
{
  voidD.39 * pD.1952;
  intD.0 initD.1951;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  # SUCC: 3 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:10000
  # PRED: 2 [100.0%]  (fallthru,exec) 5 [100.0%]  (fallthru,dfs_back,exec)
  # initD.1951_1 = PHI <0(2), initD.1951_2(5)>
  # pD.1952_3 = PHI <pD.1952_6(D)(2), pD.1952_4(5)>
  [/home/manuel/src/pr36296.c : 11] if (initD.1951_1 == 0)
    goto <bb 4>;
  else
    goto <bb 5>;
  # SUCC: 4 [29.0%]  (true,exec) 5 [71.0%]  (false,exec)

  # BLOCK 4 freq:2900
  # PRED: 3 [29.0%]  (true,exec)
  [/home/manuel/src/pr36296.c : 13] # SMT.10D.1967_13 = VDEF <SMT.10D.1967_10>
{ SMT.10D.1967 }
  pD.1952_7 = fooD.1945 ();
  # SUCC: 5 [100.0%]  (fallthru,exec)

  # BLOCK 5 freq:10000
  # PRED: 3 [71.0%]  (false,exec) 4 [100.0%]  (fallthru,exec)
  # initD.1951_2 = PHI <initD.1951_1(3), 2(4)>
  # pD.1952_4 = PHI <pD.1952_3(3), pD.1952_7(4)>
  [/home/manuel/src/pr36296.c : 16] # SMT.10D.1967_14 = VDEF <SMT.10D.1967_11>
{ SMT.10D.1967 }
  barD.1947 (pD.1952_4);
  [/home/manuel/src/pr36296.c : 17] goto <bb 3>;
  # SUCC: 3 [100.0%]  (fallthru,dfs_back,exec)

}

Because we create a PHI node for p in BB 3, we think that p can be used
uninitialized. Notice also that we are not able to move the 'if' and the call
to foo() out of the infinite loop. This is perhaps a missed optimization.


> This is quite strange: if I replace the value 2 by 1 or if I replace foo() by
> 0, the warning is no longer displayed.

If you replace foo() by 0, then CCP just assumes the p is always 0. In fact, it
will remove p altogether, even if you use 'if (init == 2)', thus missing a real
uninitialized use. This behaviour is known to hide warnings, both correct and
wrong warnings.

If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
really sounds strange. Are you sure about that?

Anyway, this is a confirmed bug but not easy to fix.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-18 23:38:16
               date|                            |
            Summary|wrong warning about         |bogus uninitialized warning
                   |potential uninitialized     |(loop representation)
                   |variable                    |


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation)

[vincent at vinc17 dot org]

------- Comment #11 from vincent at vinc17 dot org  2008-08-19 01:31 -------
(In reply to comment #10)
> If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
> really sounds strange. Are you sure about that?

Yes and here Debian's GCC 4.4 snapshot has the same behavior as GCC 4.3.1 (also
from Debian). Also, the optimized trees are not the same for 1 and 2.

vin% cat tst.c
void *foo (void);
void bar (void *);

void f (void)
{
  int init = 0;
  void *p;

  while (1)
    {
      if (init == 0)
        {
          p = foo ();
          init = INIT;
        }
      bar (p);
    }
}
vin% gcc --version
gcc.real (Debian 4.3.1-9) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vin% gcc -Wall -O2 tst.c -c -fdump-tree-optimized -DINIT=1
vin% cat tst.c.126t.optimized

;; Function f (f)

Analyzing Edge Insertions.
f ()
{
  void * p;

<bb 2>:
  p = foo ();

<bb 3>:
  bar (p);
  goto <bb 3>;

}


vin% gcc -Wall -O2 tst.c -c -fdump-tree-optimized -DINIT=2
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function
vin% cat tst.c.126t.optimized

;; Function f (f)

Analyzing Edge Insertions.
f ()
{
  void * p;
  int init;

<bb 2>:
  init = 0;

<bb 3>:
  if (init == 0)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  p = foo ();
  init = 2;

<bb 5>:
  bar (p);
  goto <bb 3>;

}


vin% /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20080802-1) 4.4.0 20080802 (experimental) [trunk revision 138551]
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vin% /usr/lib/gcc-snapshot/bin/gcc -Wall -O2 tst.c -c -DINIT=1
vin% /usr/lib/gcc-snapshot/bin/gcc -Wall -O2 tst.c -c -DINIT=2
tst.c: In function 'f':
tst.c:7: warning: 'p' may be used uninitialized in this function
vin% 


-- 


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu dot org]

------- Comment #12 from manu at gcc dot gnu dot org  2008-08-19 02:33 -------
The key difference is -ftree-vrp (which is enabled at -O2). With INIT=2, it is
missing the obvious optimization that it detects with INIT=1. I wonder if this
is expected (after all, it is value-RANGE-propagation) or there is a PR open
about this.

Notice that any two consecutive integers trigger the optimization 0,1 but also
1,2 and thus remove the bogus uninitialized warning.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|bogus uninitialized warning |bogus uninitialized warning
                   |(loop representation)       |(loop representation, VRP
                   |                            |missed-optimization)


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2008-12-25 03:00 -------
*** Bug 37361 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benoit dot hudson at gmail
                   |                            |dot com


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[av1474 at comtv dot ru]

------- Comment #14 from av1474 at comtv dot ru  2009-02-02 23:44 -------
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible. 
> 
> I think this is not only predicated PHI but our representation of loops may
> also have something to do.
> 

I'm not sure whether following warrants a new bug entry so doing it here,
sorry,
if it was inappropriate.

Following code, triggers:
 "repro.c:5: warning: 'b' may be used uninitialized in this function"
with 4.3.0 and 4.3.1 on PowerPC when invoked like this:

gcc -c -O -Wuninitialized repro.c

int f (void);

int g (int a)
{
    int b;

    if (a) b = f ();
    asm volatile ("#");
    if (a) return b;
    return 1;
}


-- 


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

[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

[manu at gcc dot gnu dot org]

------- Comment #15 from manu at gcc dot gnu dot org  2009-02-03 00:27 -------
(In reply to comment #14)
> I'm not sure whether following warrants a new bug entry so doing it here,
> sorry,
> if it was inappropriate.

That is a different case. This PR is about loops. Your case is about 
initialization and use guarded by the same predicate. I think there is already
a bug report for this. But it is always better to open a new bug report in case
of doubt.


-- 


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