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

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.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.
>From gcc-bugs-return-463152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 01:32:49 2014
Return-Path: <gcc-bugs-return-463152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28306 invoked by alias); 3 Oct 2014 01:32:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28273 invoked by uid 48); 3 Oct 2014 01:32:45 -0000
From: "bobby.prani at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63444] Compilation consumes 2.5G memory
Date: Fri, 03 Oct 2014 01:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bobby.prani at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63444-4-zluQYyvaF4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63444-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63444-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg00173.txt.bz2
Content-length: 178

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc444

--- Comment #1 from Pranith Kumar <bobby.prani at gmail dot com> ---
Just FYI, clang compiles the same file using 1G memory.