This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Java GC descriptor vs. tree_int_cst on 64-bit platforms


The problem:

Java GC descriptors on Itanium are wrong unless all pointers are located at
the beginning of the object.  I strongly suspect this applies to other 64
bit platforms (notably alpha) as well.  I'm not sure why alpha users haven't
noticed, though they may be running with a hack to disable bitmap marking.

The explanation: (?)

(I may be misunderstanding the code here.)  It looks like there is confusion
about what goes into an INTEGER_CST node, or equivalently what the arguments
to build_int_2 should be.  On a 64-bit host and target, there are two
possibilities:

1) The low and high field are 32 bits each.  (The comment in tree.def seems
to imply this.)
2) The low field is 64 bits and the high field can be ignored.  (The
declaration of struct tree_int_cst seems to imply this, since both fields
end up 64 bits wide.  So does the comment in tree.h.)

It looks like when the .s file is generated, view (1) is assumed.  When the
GC bitmap is generated (java/boehm.c:226) view (2) seems to be assumed.  In
particular, for small structures, all the interesting bits end up in the
high half of the low word, which then seem to be lost on output to the .s
file.  (In spite of the file name, I didn't write this code either, so my
interpretation of all of this may be wrong.)

Questions:

- Is there agreement that view (1) should be correct?
- If so, why are both high and low fields HOST_WIDE_INTs, which I assume are
supposed to be 64 bits on a 64-bit platform?

(Please include me or the Java list in the reply.  I'm not subscribed to
gcc@gcc.gnu.org.)

Hans


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]