This is the mail archive of the gcc-patches@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]
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).

regards

Bryce.



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