From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13935 invoked by alias); 6 Oct 2014 10:30:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 13925 invoked by uid 89); 6 Oct 2014 10:30:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 06 Oct 2014 10:30:39 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 54A2C274FC74 for ; Mon, 6 Oct 2014 12:30:36 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vTZdYLfth4b for ; Mon, 6 Oct 2014 12:30:36 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 35F70274FA95 for ; Mon, 6 Oct 2014 12:30:36 +0200 (CEST) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [patch] Fix ICE during LTRANS on big Ada application Date: Mon, 06 Oct 2014 10:30:00 -0000 Message-ID: <15700032.Vfff8vmhaG@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.29-desktop; KDE/4.7.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart4636020.XGUQcn5lqx" Content-Transfer-Encoding: 7Bit X-SW-Source: 2014-10/txt/msg00436.txt.bz2 --nextPart4636020.XGUQcn5lqx Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 2517 Hi, we have run into an ICE in LTO mode on a big Ada application with our 4.9- based compiler, whose error message is: xxxxxxxxxxxxxx.constprop.15627/1865799 (xxxxxxxxxxxxxxxxxxxxxxx.constprop) @0x7ffff6835bd0 Type: function definition analyzed Visibility: used_from_other_partition public visibility_specified visibility:hidden artificial References: __gnat_personality_v0/19663 (addr)__gnat_others_value/19664 (addr) Referring: Read from file: xxxxxx.ltrans31.o Availability: local First run: 0 Function flags: local Called by: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy.constprop.15352/1865524 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.constprop.15343/1865515 Calls: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.constprop.15628/1865800 (1.00 per call) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.part.62.lto_priv.21947/1557884 (can throw external) __gnat_end_handler/19660 (can throw external) __builtin_eh_pointer/20253 __gnat_begin_handler/19662 __gnat_end_handler/19660 (can throw external) lto1: fatal error: xxxxxx.ltrans31.o: section xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.constprop.15627 is missing So LTRANS complains that a .constprop function is missing on disk, which doesn't really make sense since it's a clone so it is not streamed. The problem is that a clone function has it clone_of field zeroed during clone materialization by cgraph_node::remove: /* We are removing node with clones. This makes clones inconsistent, but assume they will be removed subsequently and just keep clone tree intact. This can happen in unreachable function removal since we remove unreachable functions in random order, not by bottom-up walk of clone trees. */ for (n = clones; n; n = next) { next = n->next_sibling_clone; n->next_sibling_clone = NULL; n->prev_sibling_clone = NULL; n->clone_of = NULL; } because it's the clone of an inlined_to node that gets discarded because it's inlined into another clone(!). So the first clone function cannot (and is never) materialized and the compiler ICEs later when its body is requested. It seems to be that the root cause is clone_inlined_nodes overriding a master clone that has non-inline clones, hence the attached patch. Tested on x86_64-suse-linux, OK for the mainline? 2014-10-06 Eric Botcazou * ipa-inline-transform.c (can_remove_node_now_p_1): Return false for a master clone that has non-inline clones. -- Eric Botcazou --nextPart4636020.XGUQcn5lqx Content-Disposition: attachment; filename="p.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="utf-8"; name="p.diff" Content-length: 789 Index: ipa-inline-transform.c =================================================================== --- ipa-inline-transform.c (revision 215843) +++ ipa-inline-transform.c (working copy) @@ -82,6 +82,13 @@ update_noncloned_frequencies (struct cgr static bool can_remove_node_now_p_1 (struct cgraph_node *node) { + /* We cannot remove a master clone that has non-inline clones until after + these clones are materialized. */ + if (!node->clone_of) + for (struct cgraph_node *n = node->clones; n; n = n->next_sibling_clone) + if (n->decl != node->decl) + return false; + /* FIXME: When address is taken of DECL_EXTERNAL function we still can remove its offline copy, but we would need to keep unanalyzed node in the callgraph so references can point to it. */ --nextPart4636020.XGUQcn5lqx--