[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446

Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-03
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
> In an ideal world gcc would warn about the last line of make_foo() instead
> of func(), and it would mention a dangling reference instead of an
> uninitialized use.

Hum, yes, but I'm not even sure if GCC realizes that there is a dangling
reference. However, it should since the code looks like:

foo make_foo() ()
Eh tree:
   1 cleanup
     2 cleanup
{
  intD.9 & SR.1D.2273;
  intD.9 xD.2244;
  struct fooD.2226 D.2254;
  struct fooD.2226 D.2260;

;;   basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 0, next block 1, flags: (NEW, REACHABLE)
;;    pred:       ENTRY (FALLTHRU,EXECUTABLE)
;;   starting at line 10
  [test.c : 10:11] # .MEM_2 = VDEF <.MEM_1(D)>
  xD.2244 = 42;
  [test.c : 11:15] # .MEM_4 = VDEF <.MEM_2>
  [test.c : 11] MEM[(struct fooD.2226 *)&D.2260] = &xD.2244;
  # .MEM_6 = VDEF <.MEM_4>
  xD.2244 ={v} {CLOBBER};
  [test.c : 11:15] # VUSE <.MEM_6>
  return D.2260;
;;    succ:       EXIT (EXECUTABLE)

}

which is just before x = 42 is removed. But for the same reason that it is
removed, perhaps also the dangling reference could be detected.