From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18171 invoked by alias); 16 Oct 2014 16:30:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 18126 invoked by uid 55); 16 Oct 2014 16:30:18 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/63546] ICE: Segmentation fault in lto_get_decl_name_mapping on ppc64 Date: Thu, 16 Oct 2014 16:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: NEW 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: In-Reply-To: References: 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/msg01294.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63546 --- Comment #7 from Jan Hubicka --- Here we die because we do not have variable constructor in LTO stream because the variable was optimized out at compile time already. Do we still need to build RTL here? We can easily check for optimized out vars... But if we need a placeholder RTL, I suppose most practical variant would be to avoid get_variable_section from ICEing for those optimized out vars and just assume something (it is all about decision whether the var will be in rodata/rodata.rel or rodata.rel.local - definitely not relevant for dwarf2out)