https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, in the new testcase we produce thunk that is subsetquently inlined.
Inlining does not drop from_thunk_p flag and thus the call is expanded as
in-thunk call, but after inlining of course the parameters no longer correspond
to the parameters of outer function - and this is what from_thunk_p flag
promises.
I think correct fix is to clear the flag:
Index: tree-inline.c
===================================================================
--- tree-inline.c (revision 217307)
+++ tree-inline.c (working copy)
@@ -1567,9 +1567,13 @@ remap_gimple_stmt (gimple stmt, copy_bod
copy = gimple_copy (stmt);
/* Clear flags that need revisiting. */
- if (is_gimple_call (copy)
- && gimple_call_tail_p (copy))
- gimple_call_set_tail (copy, false);
+ if (is_gimple_call (copy))
+ {
+ if (gimple_call_tail_p (copy))
+ gimple_call_set_tail (copy, false);
+ if (gimple_call_from_thunk_p (copy))
+ gimple_call_set_from_thunk (copy, false);
+ }
/* Remap the region numbers for __builtin_eh_{pointer,filter},
RESX and EH_DISPATCH. */
Now however we have extra copies born in the inlined sequences. I wonder if
this is harmful (i.e. can it trigger for non-PODs that require copy
constructors?) and if we can avoid them (since they consume memory).
I think when inlining *into* the thunk call, the inliner should avoid producing
extra copies in setup_one_parameter, but it does not solve problem in question
where we are inlining the thunk.
I am testing the above patch.
