From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28805 invoked by alias); 22 Aug 2016 13:55:01 -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 28687 invoked by uid 89); 22 Aug 2016 13:55:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2862, D*cz, bodies X-HELO: mail-it0-f54.google.com Received: from mail-it0-f54.google.com (HELO mail-it0-f54.google.com) (209.85.214.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Aug 2016 13:54:50 +0000 Received: by mail-it0-f54.google.com with SMTP id e63so89896377ith.1 for ; Mon, 22 Aug 2016 06:54:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PuZ5ld7016rZSv1J5BAqurs4pj/ri6RKdOsMXgUc0W8=; b=a08xWWtVPkYrGsaXnmhMpD/df/Q/u6VWEufTmVHq0lcrah5WA79gBWa0MjEb8G8x49 pOgntozF5NzPagHIs3ZAyDucUUb6qAuBp17aCD8UMmyJVbmZccWJlfpc9jEmxoEt/qmr bVvMIJvg2L9i+JNNNuQcDrCB4uuLn9dtALa08auVFInsY0UkDyTOkQHWUZnLL6YrtUpF 3mwcb7CuE4fhFLExxzyZQP7yVs127Smt9YKL/uidynFN3iQIFyVs1fMah4yCOTI7EaKn pBiz3HiUPViHgRSzPCjnzkf0i0MBFtgXWHtYuNMnkAGB8jOYhc6uUh2ZaGrNT1F7Kab/ 4WZA== X-Gm-Message-State: AEkoous1w8Gxuhk0iJaNLaKAVb9zcAyxgO2tYMEKj8ljo7Z2Qe8qmy9HtWQb5bms0y0Rx1xG9wq6nJd8CZTfAK2y X-Received: by 10.36.225.72 with SMTP id n69mr19834845ith.16.1471874089298; Mon, 22 Aug 2016 06:54:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.208.18 with HTTP; Mon, 22 Aug 2016 06:54:47 -0700 (PDT) In-Reply-To: <20160822133316.7w7ddrwuft7svyj6@virgil.suse.cz> References: <20160809110933.2dpy7qdepugoknp2@virgil.suse.cz> <20160809181309.erlp4yxnc5otdtxm@virgil.suse.cz> <20160811125540.GA36505@kam.mff.cuni.cz> <20160812140347.GC68714@kam.mff.cuni.cz> <20160822133316.7w7ddrwuft7svyj6@virgil.suse.cz> From: Prathamesh Kulkarni Date: Mon, 22 Aug 2016 13:55:00 -0000 Message-ID: Subject: Re: [RFC] ipa bitwise constant propagation To: Prathamesh Kulkarni , Jan Hubicka , Richard Biener , Kugan Vivekanandarajah , gcc Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01534.txt.bz2 On 22 August 2016 at 19:03, Martin Jambor wrote: > 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 for the pointers. I will validate the patch after removing assert, and get back. Thanks, Prathamesh > > Thanks, > > Martin