This is the mail archive of the
mailing list for the GCC 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).