This is the mail archive of the 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]
Other format: [Raw text]

Re: [java] fix some alpha/ia64 compile failures

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).



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