From patchwork Mon Jul 5 23:50:36 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 57945 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E7872B6EEB for ; Tue, 6 Jul 2010 09:50:46 +1000 (EST) Received: (qmail 16955 invoked by alias); 5 Jul 2010 23:50:44 -0000 Received: (qmail 16944 invoked by uid 22791); 5 Jul 2010 23:50:43 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, TW_FN, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam-dmz.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jul 2010 23:50:38 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 572309AC823; Tue, 6 Jul 2010 01:50:36 +0200 (CEST) Date: Tue, 6 Jul 2010 01:50:36 +0200 From: Jan Hubicka To: gcc-patches@gcc.gnu.org, martinj@suse.cz, rguenther@suse.de Subject: Fix undefined symbols in WHOPR build of Mozilla's javascript interpretter Message-ID: <20100705235036.GC12132@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, this patch solves problem with building Mozilla javascript shell with -fwhole-program and WHOPR. The problem here is that cloning causes devirtualization. This devirtualization is recognized during virtual clone materialization (i.e. late) because Martin did not merge his IPA devritualization code yet. Because WHOPR brings the function static and house it in different file than the devirtualized call, we get undefined symbol on the partition. This problem is not limited to WHOPR only. Same problem can appear in normal compilation when call to COMDAT function is devirtualized after COMDAT was declared dead. This patch adds neccesary checking and prevents devirtualization when we can't anymore. Bootstrapped/regtested x86_64-linux, OK? Honza * gimple-fold.c (gimple_fold_obj_type_ref_known_binfo): Check that function is still available to fold into. Index: gimple-fold.c =================================================================== --- gimple-fold.c (revision 161847) +++ gimple-fold.c (working copy) @@ -1351,6 +1351,7 @@ gimple_fold_obj_type_ref_known_binfo (HO { HOST_WIDE_INT i; tree v, fndecl; + struct cgraph_node *node; v = BINFO_VIRTUALS (known_binfo); i = 0; @@ -1362,6 +1363,14 @@ gimple_fold_obj_type_ref_known_binfo (HO } fndecl = TREE_VALUE (v); + node = cgraph_get_node (fndecl); + /* When cgraph node is missing and function is public, we can not + devirtualize. This can happen in WHOPR when the actual method + ends up in other partition, because we found devirtualization + possibility too late. */ + if ((!node || !node->analyzed) + && (!TREE_PUBLIC (fndecl) || DECL_COMDAT (fndecl))) + return NULL; return build_fold_addr_expr (fndecl); }