--- 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 |Add
--- 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 th
--- 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 co
--- 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 inhib
--- 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
--- 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)
--- 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 undef
--- 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
--- 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 ini
