This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: int_cst_hash_table mapping persistence and the garbage collector
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Gary Funck <gary at intrepid dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, Tom Tromey <tromey at redhat dot com>
- Date: Tue, 11 Oct 2011 11:05:18 +0200
- Subject: Re: int_cst_hash_table mapping persistence and the garbage collector
- References: <20100708061704.GA8748@intrepid.com> <20110831001631.GH28993@intrepid.com> <20111010170213.GX8383@intrepid.com>
> In fact, the integer constant was needed because it appeared
> in the blocking factor hash table, but not via a direct pointer.
> Rather it was referenced by nature of the fact that
> the blocking factor hash table referenced the integer constant
> that is mapped in the integer constant hash table.
You'd need to elaborate here: what does "by nature of the fact that" mean?
> When the garbage collector deleted the entry from the
> "integer constant hash", it forced a new integer constant tree
> node to be created for the same (type, value) integral constant
> blocking factor.
>
> One easy way to address the current issue is to call
> tree_int_cst_equal() if the integer constant tree pointers
> do not match:
>
> if ((c1 != c2) && !tree_int_cst_equal (c1, c2))
> /* integer constants aren't equal. */
You have two objects C1 and C2 for the same constant and you're comparing them.
One was created first, say C1. If C1 was still live when C2 was created, why
was C2 created in the first class? If C1 wasn't live anymore when C2 was
created, why are you still using C1 here?
--
Eric Botcazou