On 22 August 2016 at 19:03, Martin Jambor <mjam...@suse.cz> 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