https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
2118 threshold = (unsigned HOST_WIDE_INT)PARAM_VALUE
(PARAM_LARGE_STACK_FRAME);
2119 /* In case the alloca is located at function entry, it has the same
lifetime
2120 as a declared array, so we allow a larger size. */
2121 block = gimple_block (stmt);
2122 if (!(cfun->after_inlining
2123 && TREE_CODE (BLOCK_SUPERCONTEXT (block)) == FUNCTION_DECL))
2124 threshold /= 10;
2125 if (size > threshold)
2126 return NULL_TREE;
2127
(gdb) p stmt
$2 = <gimple_call 0x7ffff6a57d80>
(gdb) p debug_gimple_stmt (stmt)
# .MEM_11 = VDEF <.MEM_10>
retAddr.2_7 = __builtin_alloca_with_align (128, 64);
$3 = void
so the fix looks obvious (well, in case the alloca_with_align really is
supposed to have no BLOCK which looks pessimizing).
Looks like we've come the
if (gimple_block (stmt))
{
... remap block tree ...
}
else
remap_blocks_to_null (DECL_INITIAL (fn), id);
path during inlining. So the call we inline wasn't associated with any BLOCK.
That's
retval.11_5 = operator new [] (_2(D), _3(D)); [tail call]
which is created from cgraph_node::expand_thunk. Indeed thunks do not have
any associated BLOCK.
Testing fix.
