Richard Guenther wrote:
>> OK, thanks. If you have any suggestions on other approaches to
>> verifying this, I'd certainly appreciate it.
> Other than testing on more targets, no. Does it fix PR25505? In
> this case it would be a fix for a regression and maybe rth can have a
> look at the patch as he should know this area equally well?
PR25505 reports that the stack usage of a particular function increased
from 512 bytes to 20k from 3.3 -> 4.x. This patch reduces the stack
usage for that function back to ~13k. So, it solves one aspect of the
regression. I'll attach the patch I've been testing.
- Josh
Index: gcc/calls.c
===================================================================
--- gcc/calls.c (revision 116236)
+++ gcc/calls.c (working copy)
@@ -1987,7 +1987,6 @@ expand_call (tree exp, rtx target, int i
we would have no way of knowing when to free it. */
rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1);
- mark_temp_addr_taken (d);
structure_value_addr = XEXP (d, 0);
target = 0;
}
