This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [java] fix some alpha/ia64 compile failures
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: Richard Henderson <rth at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sat, 22 Dec 2001 14:04:04 +1300
- Subject: Re: [java] fix some alpha/ia64 compile failures
- References: <20011221114102.A30454@redhat.com>
Richard Henderson wrote:
>Any symbol that is not defined in the current object file must be
>marked DECL_EXTERNAL. This fixes around 60 failures of the form
>
> ld: gp-relative relocation against dynamic symbol _Jv_intClass
>
Actually, references to these symbols should never be generated from
Java code. GCJ used to remap "int.class" and "java.lang.Integer.TYPE" to
_Jv_intClass, but now they both should generate a reference to
java.lang.Integer.TYPE, which is what the JLS says.
I think the stuff to still generate a _Jv_fooClass reference in
build_class_ref is just cruft - can you tell where it is being called
from in this case?
>There is one more similar failure (PR375) where the target of the
>relocation is instead java::lang::Boolean::TRUE, but I have no
>idea how to fix it.
>
Boolean.TRUE is just an ordinary static field so it seems odd that this
would cause problems specifically. Does this occur during the libjava
build or on some other code? I couldn't find the PR you mentioned.
> The DECL is created in add_field, and the
>correct solution would appear to be to test
>
> is_compiled_class (class) != 2
>
>except that read_class always sets current_class to the class
>being loaded, so is_compiled_class always equals 2 at this point.
>
Thats probibly a bug. I'm not sure that is_compiled_class always works
reliably during the early stages of compilation (ie before
java_expand_classes is called).
regards
Bryce.