From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1941 invoked by alias); 22 Aug 2016 13:33:25 -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 1918 invoked by uid 89); 22 Aug 2016 13:33:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=martins, sk:fno-dia, sk:fnodia, nevertheless X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Aug 2016 13:33:19 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AE9A2AAF2; Mon, 22 Aug 2016 13:33:16 +0000 (UTC) Date: Mon, 22 Aug 2016 13:33:00 -0000 From: Martin Jambor To: Prathamesh Kulkarni Cc: Jan Hubicka , Richard Biener , Kugan Vivekanandarajah , gcc Patches Subject: Re: [RFC] ipa bitwise constant propagation Message-ID: <20160822133316.7w7ddrwuft7svyj6@virgil.suse.cz> Mail-Followup-To: Prathamesh Kulkarni , Jan Hubicka , Richard Biener , Kugan Vivekanandarajah , gcc Patches References: <20160809110933.2dpy7qdepugoknp2@virgil.suse.cz> <20160809181309.erlp4yxnc5otdtxm@virgil.suse.cz> <20160811125540.GA36505@kam.mff.cuni.cz> <20160812140347.GC68714@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-06-11) X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01532.txt.bz2 Hi, On Tue, Aug 16, 2016 at 06:34:48PM +0530, Prathamesh Kulkarni wrote: > Thanks, I updated the patch to address these issues (attached). > However the patch caused ICE during testing > objc.dg/torture/forward-1.m (and few others but with same ICE): > > Command line options: > /home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/gcc/xgcc > -B/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/gcc/ > /home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/gcc/gcc/testsuite/objc.dg/torture/forward-1.m > -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto > -fuse-linker-plugin -fno-fat-lto-objects -fgnu-runtime > -I/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/gcc/gcc/testsuite/../../libobjc > -B/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/x86_64-pc-linux-gnu/./libobjc/.libs > -L/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/x86_64-pc-linux-gnu/./libobjc/.libs > -lobjc -lm -o ./forward-1.exe > > Backtrace: > 0x8c0ed2 ipa_get_param_decl_index_1 > ../../gcc/gcc/ipa-prop.c:106 > 0x8b7dbb will_be_nonconstant_predicate > ../../gcc/gcc/ipa-inline-analysis.c:2110 > 0x8b7dbb estimate_function_body_sizes > ../../gcc/gcc/ipa-inline-analysis.c:2739 > 0x8bae26 compute_inline_parameters(cgraph_node*, bool) > ../../gcc/gcc/ipa-inline-analysis.c:3030 > 0x8bb309 inline_analyze_function(cgraph_node*) > ../../gcc/gcc/ipa-inline-analysis.c:4157 > 0x11dc402 ipa_icf::sem_function::merge(ipa_icf::sem_item*) > ../../gcc/gcc/ipa-icf.c:1345 > 0x11d6334 ipa_icf::sem_item_optimizer::merge_classes(unsigned int) > ../../gcc/gcc/ipa-icf.c:3461 > 0x11e12c6 ipa_icf::sem_item_optimizer::execute() > ../../gcc/gcc/ipa-icf.c:2636 > 0x11e34d6 ipa_icf_driver > ../../gcc/gcc/ipa-icf.c:3538 > 0x11e34d6 ipa_icf::pass_ipa_icf::execute(function*) > ../../gcc/gcc/ipa-icf.c:3585 > > This appears due to following assert in ipa_get_param_decl_index_1(): > gcc_checking_assert (!flag_wpa); > which was added by Martin's patch introducing ipa_get_type(). > Removing the assert works, however I am not sure if that's the correct thing. > I would be grateful for suggestions on how to handle this case. > I wrote that the patch was not really tested, I did not think about ICF loading bodies and re-running body-analyses at WPO time. Nevertheless, after some consideration, I think that just removing the assert is fine. After all, the caller must have passed a PARM_DECL if it is doing anything sensible at all and that means we have access to the function body. Thanks, Martin