On 10/13/11 06:15:31, Laurynas Biveinis wrote:
[...] In your case (correct me if I misunderstood something)
you have one hash table, marking of which will mark more objects
which are required for the correct marking of the second hash table.
GC might be simply walking the second one first.
2011/10/13 Gary Funck g...@intrepid.com:
On 10/13/11 06:15:31, Laurynas Biveinis wrote:
[...] In your case (correct me if I misunderstood something)
you have one hash table, marking of which will mark more objects
which are required for the correct marking of the second hash table.
GC might
On 10/11/11 11:05:18, Eric Botcazou wrote:
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
The problem is that the references to object C1 and C2 live in
a hash table, and that although the referenced nodes will be retained
by the garbage collector, their mapping in int_cst_hash_table is
deleted by the GC.
This isn't a simple hash table, is it?
I am not familiar with the details
It maps a type node into a corresponding integer node that is
the blocking factor associated with the type node. Before
the advent of this hash table the blocking factor was stored
in a dedicated field in the tree type node. The suggestion was
made to move this into a hash table to save
On Wed, Oct 12, 2011 at 10:29 AM, Eric Botcazou ebotca...@adacore.com wrote:
It maps a type node into a corresponding integer node that is
the blocking factor associated with the type node. Before
the advent of this hash table the blocking factor was stored
in a dedicated field in the tree
On 10/12/11 14:00:54, Richard Guenther wrote:
I think there is an issue when two cache htabs refer to each other
with respect to GC, you might search the list to find out more.
Richard, thanks. I thought that might be the case, but
I don't understand the GC well enough to make this
I think there is an issue when two cache htabs refer to each other
with respect to GC, you might search the list to find out more.
I'm not sure this is the case here, there seems to be a clear hierarchy.
--
Eric Botcazou
2011/10/11 Gary Funck g...@intrepid.com:
static GTY ((if_marked (tree_map_marked_p),
param_is (struct tree_map)))
htab_t upc_block_factor_for_type;
[...]
upc_block_factor_for_type = htab_create_ggc (512, tree_map_hash,
tree_map_eq,
On Mon, Oct 10, 2011 at 7:02 PM, Gary Funck g...@intrepid.com wrote:
Recently, a few UPC test programs failed to compile
due to mis-matches of parameters in a prototype and its
corresponding function definition. The mis-match was
based upon the apparent inequality of UPC layout qualifiers
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.
On 10/11/11 10:24:52, Richard Guenther wrote:
GF: 1. Is it valid to assume that pointer equality is sufficient
GF: to compare two integer constants for equality as long as they
GF: have identical type and value?
Yes, if both constants are live
The upc blocking factor hash table is declared
12 matches
Mail list logo
