https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580
Jan Hubicka <hubicka at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> --- 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?