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.
