> 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
