[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- 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
--- 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] wrong warning about potential uninitialized variable
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
