[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
$ ~/test1/205036M/build/gcc/cc1 -O1  -Wuninitialized  test.c
-fdump-tree-all-all-lineno
$ cat test.c.139t.uninit1

foo (intD.6 iD.1789)
{
  intD.6 jD.1792;
  intD.6 _5;
  intD.6 _7;

;;   basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 0, next block 5, flags: (NEW, REACHABLE)
;;    pred:       ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
;;   starting at line 10
  [test.c : 10:11] # .MEM_4 = VDEF <.MEM_2(D)>
  # USE = nonlocal { D.1792 } (escaped)
  # CLB = nonlocal { D.1792 } (escaped)
  _5 = barD.1786 (i_3(D));
  [test.c : 10:6] if (_5 != 0)
    goto <bb 3>;
  else
    goto <bb 5>;
;;    succ:       3 [39.0%]  (TRUE_VALUE,EXECUTABLE)
;;                5 [61.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 0, count 0, freq 6102, maybe hot
;;    prev block 2, next block 3, flags: (NEW)
;;    pred:       2 [61.0%]  (FALSE_VALUE,EXECUTABLE)
;;
  goto <bb 4>;
;;    succ:       4 [100.0%]  (FALLTHRU)

;;   basic block 3, loop depth 0, count 0, freq 3898, maybe hot
;;    prev block 5, next block 4, flags: (NEW, REACHABLE)
;;    pred:       2 [39.0%]  (TRUE_VALUE,EXECUTABLE)
;;   starting at line 11
  [test.c : 11:9] # .MEM_6 = VDEF <.MEM_4>
  # USE = nonlocal { D.1792 } (escaped)
  # CLB = nonlocal { D.1792 } (escaped)
  bazD.1788 ([test.c : 11] &jD.1792);
;;    succ:       4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 3, next block 1, flags: (NEW, REACHABLE)
;;    pred:       5 [100.0%]  (FALLTHRU)
;;                3 [100.0%]  (FALLTHRU,EXECUTABLE)
;;   starting at line 14
  # .MEM_1 = PHI <.MEM_4(5), .MEM_6(3)>
  [test.c : 14:3] # VUSE <.MEM_1>
  _7 = jD.1792;
  # .MEM_8 = VDEF <.MEM_1>
  jD.1792 ={v} {CLOBBER};
  [test.c : 14:3] # VUSE <.MEM_8>
  return _7;
;;    succ:       EXIT [100.0%]

}

It seems one could follow every operand of the MEM_1 PHI node until you find
the MEM_4 = VDEF <.MEM_2(D)>. But perhaps this may produce a lot of false
positives.

The uninit pass avoids virtual operands on purpose, so it cannot be that
trivial.

-- 
You are receiving this mail because:
You are on the CC list for the bug.