https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 13 Jul 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216 > > --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > I guess lambdas really need to have all the needed parameters captured, and > for > VLAs that likely includes not just the VLAs themselves, but their sizes as > well. > That is something that needs to be done in the FE somewhere, because lambdas > are handled only at that point. Wonder if that means also creating another > set > of the VLA types for the lambda with TYPE_SIZE{,_UNIT} that map to an > artificial field and that the capturing code initializes it with the > TYPE_SIZE{,_UNIT} (i.e. the SAVE_EXPR it has). For normal nested functions (C > or Fortran) this is tree-nested.c's job and I think we handle it there already > right, because it is after gimplification and so the needed vars are exposed. Yeah, though the "new" issue is that while previously tree sharing between nested functions and the respective locals that are defined in the wrong function are resolved by unnesting (also the reason we need to gimplify outer-to-inner and only lower nested functions after that) since we are generating SSA temporaries we'll have cross-function SSA names for such tree sharing. That isn't resolved by unnesting and this is what the pasted patch snippet fixes also for non-lambdas. I think that either the tree sharing is a bug or the gimplifier woring in-place (and thus its need to unshare in the first place) is the bug here. The SSA temporaries by gimplification are new since GCC 7 so we somehow didn't run into this before. > Or reject capturing VLAs (with a sorry) until that is done. Possibly, given VLAs are a GNU extension.
