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

[Richard Henderson <rth at cygnus dot com>]

On Tue, Mar 27, 2001 at 05:57:28PM -0800, Boehm, Hans wrote:
> Meaning there is agreement that low contains all 64 bits in this case, and
> the comment around line 262 of tree.def is wrong?

Yes.  An INTEGER_CST can represent a 128-bit integer if the
host is using a 64-bit HOST_WIDE_INT.

> Get_boehm_type_descriptor should be returning a one word long constant.  It
> currently returns a constant generated with build_int_2

get_boehm_type_descriptor, and in particular set_bit, appears
to be correct in their bit manipulations.

> ... which is always a 32 bit constant, even on a 64 bit platform.

Err, well, not precisely.  It's integer_type_node, so whatever "int"
happens to be on the target.  Which would be 64 bits on a T3E.

> The function should be setting TREE_TYPE(value) to be a pointer
> length integer at the end.  There seems to be no way to do this
> in the Java front end without an explicit test on the size of a pointer?

Which pointer type do you mean?  The type as it exists in memory,
or the type as it must exist in a register to be used?  Think ilp32
on ia64, which still uses 64 bits in a register.

I'm guessing you mean the in-memory pointer size.

  type_for_mode (ptr_mode, MODE_INT)

If not, use Pmode instead of ptr_mode.

Or, actually, if you're not playing odd structure layout games,
there's no reason to be concerned with pointer size at all.  You'd
want to use the largest thing easily manipulated on the target, 
which would be word_mode.  Again, think ia64 ilp32 which can still
manipulate 64-bit words.


r~