From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-353690-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 3683 invoked by alias); 15 Apr 2011 22:52:18 -0000
Received: (qmail 3671 invoked by uid 22791); 15 Apr 2011 22:52:17 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Apr 2011 22:52:12 +0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-48492-4-xPdPPC2dsS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-48492-4@http.gcc.gnu.org/bugzilla/>
References: <bug-48492-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Fri, 15 Apr 2011 22:52:00 -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
X-SW-Source: 2011-04/txt/msg01594.txt.bz2

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

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-04-15 22:52:08 UTC ---
The scenario is as follows:
  1. during LTO stage, copy-prop eliminates a DECL_IN_CONSTANT_POOL variable
from the GIMPLE IR, except for a reference in a GIMPLE_DEBUG statement
(ADDR_EXPR of the variable is the debug value),
  2. the variable is streamed out in the object file, as well as its associated
varpool entry,
  3. during WPA stage, both are streamed in, then reachability analysis is run
and computes that the variable is unreachable so removes the varpool entry.
As a consequence, when the variable is streamed out again, its initializer gets
replaced with ERROR_MARK.
  4. during LTRANS stage, the variable is again streamed in, with ERROR_MARK as
initializer and this blows up when the GIMPLE_DEBUG statement is processed.

So ISTM that the problem is in the reachability analysis during the WPA stage.