2011/10/13 Gary Funck :
> 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
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/11 Gary Funck :
> 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, 0);
>
> I
> 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
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 determinat
On Wed, Oct 12, 2011 at 10:29 AM, Eric Botcazou 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 type node. Th
> 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 sa
On 10/12/11 09:27:43, Eric Botcazou wrote:
> > 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 simpl
> 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 deta
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
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 dec
> 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 tabl
On Mon, Oct 10, 2011 at 7:02 PM, Gary Funck 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
> (blocking facto
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
(blocking factors).
UPC blocking factors are integer constants. They are
re
14 matches
Mail list logo
