[Bug c/77754] [5/6/7 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
VLA side effects in function declarations that are not definitions should 
be discarded.  VLA side effects in function declarations that are 
definitions should occur on entry to the function (this applies both to 
side effects from sizes of array parameters, which do not affect the 
function type because those parameters get adjusted to pointers, and to 
side effects from sizes in parameters involving pointers to VLAs, which do 
affect the type).  See C11 6.9.1#10: "On entry to the function, the size 
expressions of each variably modified parameter are evaluated ...".

The general principle is that where expressions that might have side 
effects are involved in types, the C front end arranges the trees it 
generates so that those expressions are explicitly evaluated first at a 
point chosen by the front end - for example, by inserting a statement to 
evaluate them before the declaration.  Thus, if language-independent 
gimplifier code recurses into a type and finds a SAVE_EXPR there, it 
should always find that the SAVE_EXPR in question has already been 
evaluated as a result of the separate code explicitly inserted by the 
front end.

Now, maybe that isn't possible for this case of expressions involved in 
function arguments.  There, the relevant front-end code is in 
store_parm_decls processing arg_info->pending_sizes.  The pending_sizes 
expression should include all relevant expressions (modulo bug 77767 which 
I just found and reported while looking at the present issue), not just 
those for parameters declared as VLAs.  But I don't know whether the code 
this inserts occurs before or after the language-indpendent code dealing 
with VLAs involved in function arguments.

Thus: for VLAs involved in function arguments in declarations (or type 
names, etc.) that are not definitions, the front end is expecting the 
language-independent compiler to treat them as [*], not to insert code to 
evaluate them (and the front end has no code that uses pending_sizes in 
such a case, so implicitly discards them).  If the language-independent 
compiler does not have such semantics, that implies a lowering step is 
needed for any declaration or type name involving such a function type at 
any level of indirection.

For VLAs involved in function arguments in definitions, if 
language-independent code ever inserts evaluations outside the function in 
question, including in the case of nested functions, that's definitely 
wrong, and ideally for the front end it would be able to provide the 
pending_sizes information in some way so that the language-independent 
code does not insert its own evaluations of sizes, just verifies that the 
SAVE_EXPRs in question were already evaluated.