https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790
--- Comment #32 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 12 Feb 2025, jakub at gcc dot gnu.org wrote: > 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. Hmm, so CFG expand pruning all local_decls interferes with GC then. Can we avoid pruning it completely? Two-stage handling of cache hash tables would work and is probably a safe fix, but then it also feels somewhat expensive (IMO with checking we should assert we're _not_ getting any unmarked entries marked with this approach). Inlining DECL_VALUE_EXPR is an interesting idea, but it feels like unchartered territory at this point.
