From patchwork Tue Mar 25 00:07:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 333202 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 8E90314008C for ; Tue, 25 Mar 2014 11:07:26 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=YlvcNzunnICKwzsxc GDpnj/FEecgt8dsU3ytv/rR/SWAeWl3CjtFnTN5n0BPEUCVx7eN5awkhZGSO4nZF 67Y07JsQsPm+xGo6d4ZnkKhI+ohfxO+CD9oIV+TtHsCbhiPdR4kfnonhsoxseHFf qmUvD0psNzzbnhFw5KdCgHPlMg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=RZJS4PbC07RhuI6Mrk9l3Oy tJ9w=; b=lrEHfR9kmiHS2ATwYOn70oAqh3fcnJAZE/JbZQgUQlwDnHvWoSLu1Hg 95TRF8U6rmO52AaYYNzmOhgrSE34fb8Q56SG/mm/AAkUQ9rt0Tzqpq2Fb1yeGeJr 7b3D5z3V+rHeP+yDw9FU4uGfkIufSTrFmihXGIJzLZIDvHycF8ug= Received: (qmail 9929 invoked by alias); 25 Mar 2014 00:07:20 -0000 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 Received: (qmail 9920 invoked by uid 89); 25 Mar 2014 00:07:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 25 Mar 2014 00:07:17 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 0CD45543C95; Tue, 25 Mar 2014 01:07:13 +0100 (CET) Date: Tue, 25 Mar 2014 01:07:13 +0100 From: Jan Hubicka To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Jan Hubicka , Jakub Jelinek Subject: Re: [PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO Message-ID: <20140325000713.GA22285@kam.mff.cuni.cz> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) > > Currently a _lot_ of packages fail to build with LTO because LTO > messes up fortify wrappers by replacing the call to the alias with > the symbol itself, making the wrapper look like infinitely > recursing. > > The following patch fixes this by dropping the bodies of > DECL_EXTERN always-inline functions on the floor before IPA > (and when doing LTO). IMHO we should at some point do this > unconditional on LTO as the early inliner is supposed to > remove all references to always-inline functions. > > I'm not 100% sure about the cgraph API use to drop the function > body, but at least it seems to work ;) I'm not sure if we want > to restrict the set of functions to apply this even more than > just those with always-inline and DECL_EXTERNAL set? > > Now double-checking with a fortified LTO bootstrap. > > Ok for trunk? > > Thanks, > Richard. > > 2014-03-24 Richard Biener > > PR lto/59626 > * passes.c (ipa_write_summaries): Drop function bodies of > extern always-inline functions. > > * gcc.dg/lto/pr59626_0.c: New testcase. > * gcc.dg/lto/pr59626_1.c: Likewise. > Hi, do you see some problem with this approach? Unlike in dropping for ipa_write_summaries it drops just after early optimizations and it is done unconditonally. I see it kills every cross module inlining of extern inlines, but so does your patch. This may make difference for C++ implicit extern inlines (keyed functions) where I can imagine users both to declare them always inline and then call indirectly... I do it unconditionally because I do not like much of idea of making the LTO and non-LTO pipelines diverging even more. Honza Index: ipa.c =================================================================== --- ipa.c (revision 208798) +++ ipa.c (working copy) @@ -139,7 +139,10 @@ process_references (struct ipa_ref_list if (node->definition && !node->in_other_partition && ((!DECL_EXTERNAL (node->decl) || node->alias) - || (before_inlining_p + || (((before_inlining_p + && (cgraph_state < CGRAPH_STATE_IPA_SSA + || !lookup_attribute ("always_inline", + DECL_ATTRIBUTES (node->decl))))) /* We use variable constructors during late complation for constant folding. Keep references alive so partitioning knows about potential references. */ @@ -191,7 +194,10 @@ walk_polymorphic_call_targets (pointer_s /* Prior inlining, keep alive bodies of possible targets for devirtualization. */ if (n->definition - && before_inlining_p) + && (before_inlining_p + && (cgraph_state < CGRAPH_STATE_IPA_SSA + || !lookup_attribute ("always_inline", + DECL_ATTRIBUTES (n->decl))))) pointer_set_insert (reachable, n); /* Even after inlining we want to keep the possible targets in the