https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 7 Nov 2019, joseph at codesourcery dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088 > > --- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery > dot com> --- > Yes, pointers to VLA are variably modified (but are OK in function > arguments even for extern functions, as VLAs there get treated as [*]). > > So maybe you should use C_TYPE_VARIABLE_SIZE as the test on the types of > the arguments (and the return value, or is it OK for that to be > variable-size?). OK, will check with C_TYPE_VARIABLE_SIZE. The cases with VLA return types I saw all used RSO which works fine, we wouldn't handle other cases OK. VLAs really are all the same as C++ classes with non-trivial CTORs (where the types are TREE_ADDRESSABLE) here. Which is also why we should pass VLAs by reference (and have the FE set up the non-trivial copy at the caller). So for more appropriate middle-end handling we maybe should set TREE_ADDRESSABLE on C_TYPE_VARIABLE_SIZE types? So as said, avoiding the inlining with the proposed patch is just a workaround for missing FE support for passing VLAs by value. I think the middle-end "knows" how to handle the complication of passing the argument by seeing WITH_SIZE_EXPR on it, likewise for stores from a return value where WITH_SIZE_EXPR should appear on the LHS. Guess I need to find a testcase to trigger this with inlining and no RSO but it looks like the gimplifier always forces RSO for VLA returns: else if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (*to_p))) != INTEGER_CST) /* Always use the target and thus RSO for variable-sized types. GIMPLE cannot deal with a variable-sized assignment embedded in a call statement. */ use_target = true; but the gimplifier cannot do the same for arguments (DECL_BY_REFERENCE). Using DECL_BY_REFERENCE in the FE requires adjustments to how it builds calls to VLA typed functions, I'm not set up to dig into that.
