RE: Java GC descriptor vs. tree_int_cst on 64-bit platforms

["Boehm, Hans" <hans_boehm at hp dot com>]

GCBench fails as a test case for this for two reasons:

1) It may not do enough checking to notice a failure.  It does just enough
checking to hopefully discourage compilers from eliminating too much dead
code.

2) All the pointers are at the beginning of the objects.  Thus they end up
being described by lengths, not bit maps.  And those always fit in 32 bits.

If you need a test case, I can generate one.  (Repeated reversals of lists
of integers should be good,  provided the integer field in the list node
comes first.)

Hans

P.S. I'd appreciate it if someone could check in a fix for the comment in
tree.def describing INTEGER_CST.  I think it should say something like:

/* Contents are in TREE_INT_CST_LOW and TREE_INT_CST_HIGH fields,
   a HOST_WIDE_INT each, giving us a 64 bit constant capability
   on a 32 bit host.
   Note: constants of type char in Pascal are INTEGER_CST,
   and so are pointer constants such as nil in Pascal or NULL in C.
   `(int *) 1' in C also results in an INTEGER_CST.  */

instead of

/* Contents are in TREE_INT_CST_LOW and TREE_INT_CST_HIGH fields,
   32 bits each, giving us a 64 bit constant capability.
   Note: constants of type char in Pascal are INTEGER_CST,
   and so are pointer constants such as nil in Pascal or NULL in C.
   `(int *) 1' in C also results in an INTEGER_CST.  */

> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]

> I don't have any small testcases that demonstrate the problem 
> reliably,
> not even GCBench.  But I've seen a problem on Alpha 
> consistent with what
> Hans describes.
>