http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
--- Comment #4 from davidxl <xinliangli at gmail dot com> 2011-06-30 20:37:36
UTC ---
I can to reproduce the problem on x86-64 linux. Can you help provide the
following dump:
-fdump-tree-uninit-blocks-details?
Thanks,
David
(In reply to comment #3)
> Frankly, I'm just not able to wrap my head around the tree-ssa-uninit
> implementation. I understand the general concepts, but just can't seem to
> find
> where in that code we handle certain things. Perhaps it simply doesn't handle
> them.
>
> In this simpler sample code we have:
>
> /* { dg-do compile } */
> /* { dg-options "-Wuninitialized -O2" } */
>
> int g;
> void bar();
> void blah(int);
>
> int foo (int n, int l, int m, int r)
> {
> int v;
>
> if (n < 10 || m > 100)
> v = r;
>
> if (m) g++;
>
> if ( n < 10 || m > 100)
> blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
>
> return 0;
> }
>
> Compiling with -O2 -Wuninitialized on cris-elf.
>
> Someone who knows the code in tree-ssa-uninit.c really needs to chime in...
> Reading that code just makes my head hurt.
>
> From the standpoint of the resulting CFG, the path 2->8->4->5->6 can never be
> traversed, nor can 2->3->9->4->6. 2->3->9->4->5 is properly guarded as far as
> I can tell, though I'm not convinced tree-ssa-uninit.c is computing the guards
> correctly.
