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.
> 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
