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

2008-08-18 Thread 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

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

2008-08-18 Thread 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

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

2008-05-28 Thread 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

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

2008-05-28 Thread 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

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

2008-05-22 Thread 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

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

2008-05-22 Thread 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

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

2008-05-22 Thread 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

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

2008-05-22 Thread 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

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

2008-05-22 Thread 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