https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790
--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #30) > > Note, normally these VLA addresses don't have DECL_VALUE_EXPR and so are > > usually used in the IL. It is just that tree-nested.cc in this case added > > DECL_VALUE_EXPR on those because they are (or were) referenced from nested > > function. > > I think the intent for this is to reflect this into debug info. So, > ... I think tree-nested.cc should put amend the related VAR which should > be already somewhere in BLOCK_VARS? Note, moving it to BLOCK_VARS is actually wrong, the VAR_DECL is DECL_ARTIFICIAL, but !DECL_IGNORED_P - we actually want to be able to use its value. We don't want users to see id_string.55 in the debugger and be able to ask its value etc. We just want users to look at id_string which is a VLA. So, from dwarf2out.cc POV, we want to know where id_string lives and go there through the the DECL_VALUE_EXPRs character(kind=1) id_string[1:.id_string] [value-expr: *id_string.55]; character(kind=1)[1:.id_string] * id_string.55 [value-expr: FRAME.107.id_string.55]; integer(kind=8) .id_string [value-expr: FRAME.107..id_string]; to actual RTL and DWARF expressions for that. So, conceptually I think we want to keep current behavior but ensure that chains of DECL_VALUE_EXPRs still work after GC. One way to achieve that could be some special GTY extension which does the 2 pass swipes over the hash_map rather than one pass (could say GTY((user)) deal with that?). And another possibility would be to "inline" the DECL_VALUE_EXPR subtrees, when we note that id_string DECL_VALUE_EXPR refers to id_string.55 which is not in any BLOCK_VARS and has DECL_VALUE_EXPR, simply take its DECL_VALUE_EXPR and replace id_string.55 with that in DECL_VALUE_EXPR of id_string, etc.
