[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 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
--- 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 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 #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