On Fri, 14 Feb 2025, Jakub Jelinek wrote: > On Thu, Feb 13, 2025 at 05:21:56PM +0100, Jakub Jelinek wrote: > > The ggc_set_mark call in gt_value_expr_mark_2 is actually wrong, that > > just marks the VAR_DECL itself, but doesn't mark the subtrees of it (type > > etc.). So, I think we need to test gcc_marked_p for whether it is marked > > or not, if not marked walk the DECL_VALUE_EXPR and then gt_ggc_mx mark > > the VAR_DECL that was determined not marked and needs to be marked now. > > One option would be to call gt_ggc_mx (t) right after the DECL_VALUE_EXPR > > walking, but I'm a little bit worried that the subtree marking could mark > > other VAR_DECLs (e.g. seen from DECL_SIZE or TREE_TYPE and the like) and > > if they would be DECL_HAS_VALUE_EXPR_P we might not walk their > > DECL_VALUE_EXPR anymore later. > > So, the patch defers the gt_ggc_mx calls until we've walked all the > > DECL_VALUE_EXPRs directly or indirectly connected to already marked > > VAR_DECLs. > > > > Ok for trunk if this passes bootstrap/regtest? > > FYI, bootstrapped/regtested successfully on x86_64-linux and i686-linux.
OK. It gets all a bit awkard now, so I do wonder whether marking DECL_VALUE_EXPR from 'tree' marking is more robust. IIRC we used to have a flag on the tree whether there is a DECL_VALUE_EXPR recorded, so no hashtable lookup should be needed? Thanks, Richard. > > 2025-02-13 Jakub Jelinek <ja...@redhat.com> > > > > PR debug/118790 > > * tree.cc (struct gt_value_expr_mark_data): New type. > > (gt_value_expr_mark_2): Don't call ggc_set_mark, instead check > > ggc_marked_p. Treat data as gt_value_expr_mark_data * with pset > > in it rather than address of the pset itself and push to be marked > > VAR_DECLs into to_mark vec. > > (gt_value_expr_mark_1): Change argument from hash_set<tree> * > > to gt_value_expr_mark_data * and find pset in it. > > (gt_value_expr_mark): Pass to traverse_noresize address of > > gt_value_expr_mark_data object rather than hash_table<tree> and > > for all entries in the to_mark vector after the traversal call > > gt_ggc_mx. > > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
