From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4005 invoked by alias); 30 Oct 2014 13:45:11 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 3893 invoked by uid 48); 30 Oct 2014 13:45:02 -0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/63580] [5 Regression] ICE : error: invalid argument to gimple call Date: Thu, 30 Oct 2014 14:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-10/txt/msg02405.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580 Jan Hubicka changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka --- Hmm, I think we may get confused by having ADDRESSABLE flag set because the original function body took its address and it makes sense to clear it as Martin suggest. I am bit confused on why this leads to ICE - I think false positive on ADDRESSABLE flag ought to make cgraphunit to introduce extra copy in: if (nargs) for (i = 1, arg = DECL_CHAIN (a); i < nargs; i++, arg = DECL_CHAIN (arg)) { tree tmp = arg; if (!is_gimple_val (arg)) { tmp = create_tmp_reg (TYPE_MAIN_VARIANT (TREE_TYPE (arg)), "arg"); gimple stmt = gimple_build_assign (tmp, arg); gsi_insert_after (&bsi, stmt, GSI_NEW_STMT); } vargs.quick_push (tmp); } that may later end up on stack and prevent call from being a tail call. I see that later optimizers may not be able to optimize out the extra copy simply because it is bit hard to do: one needs to verify that the original location is dead and possibly may be rewritten by a callee. I did not find any code that would prevent clearning ADDRESSABLE flag on parameters, so I think Martin's patch is correct. Additionally I think it is not safe to set TAILCALL flag if the code above introduced a local variable. This is becuase setting this flag by hand bypasses logic in suitable_for_tail_call_opt_p that prevents tail call conversion when any ADDRESSABLE vars exists. I did not find any reasons why ADDRESSABLE flag should be set on parameter besides the usual case that it has address taken, so I tink Martin's patch is OK and correct fix. Martin, does it fix the other PR too?