https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790
--- Comment #36 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:74ea20e16cf18b42071557b71a42ea31c8192425 commit r15-7526-g74ea20e16cf18b42071557b71a42ea31c8192425 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Feb 14 12:01:13 2025 +0100 tree: Fix up the DECL_VALUE_EXPR GC marking [PR118790] 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. 2025-02-14 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.
