[Bug tree-optimization/67055] [5/6 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c

[rguenth at gcc dot gnu.org]

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.