From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: I'm getting the following ICE from gcj... org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java: In class 'org.gudy.azureus2.core3.peer.impl.PEPieceImpl': org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java: In constructor '(org.gudy.azureus2.core3.peer.PEPeerManager,org.gudy.azureus2.core3.disk.DiskManagerPiece,int)': org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. I'm about to upload a tarball for the test code. Untar it and reproduce with... gcj -c -g -fPIC -findirect-dispatch -fjni -c org/gudy/azureus2/core3/peer/impl/PEPieceImpl.class Removing -findirect-dispatch makes the problem go away. This is on x86-64. I haven't tried x86 or other platforms. Version-Release number of selected component (if applicable): gcc-java-4.1.0-0.23 How reproducible: Always Steps to Reproduce: 1. gcj -c -g -fPIC -findirect-dispatch -fjni -c org/gudy/azureus2/core3/peer/impl/PEPieceImpl.class 2. 3. Additional info:
Created attachment 124346 [details] Tarball with test code.
This is a segfault in dwarf2out.c: at ../../gcc/dwarf2out.c:11416 11416 if (TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type)) (gdb) l 11411 { 11412 gen_type_die (type, context_die); 11413 11414 /* If we're trying to avoid duplicate debug info, we may not have 11415 emitted the member decl for this function. Emit it now. */ 11416 if (TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type)) 11417 && ! lookup_decl_die (member)) 11418 { 11419 dw_die_ref type_die; 11420 gcc_assert (!decl_ultimate_origin (member)); (gdb) p debug_tree (type) <record_type 0x2a98dec790 boolean[] type <boolean_type 0x2a98d940b0 boolean asm_written public unsigned QI size <integer_cst 0x2a98d7b630 constant invariant 8> unit size <integer_cst 0x2a98d7b660 constant invariant 1> align 8 symtab -1729758400 alias set -1 precision 1 min <integer_cst 0x2a98d92210 0> max <integer_cst 0x2a98d92240 1> pointer_to_this <pointer_type 0x2a98dec9a0> chain <type_decl 0x2a98d8b820 boolean>> asm_written type_1 BLK size <integer_cst 0x2a98d7bdb0 type <integer_type 0x2a98d870b0 bit_size_type> constant invariant 128> unit size <integer_cst 0x2a98d7bde0 type <integer_type 0x2a98d87000> constant invariant 16> align 64 symtab -1729759040 alias set -1 fields <field_decl 0x2a98d9e6c0 D.413 type <record_type 0x2a98d974d0 java.lang.Object tree_3 type_2 type_4 DI size <integer_cst 0x2a98d7ba50 constant invariant 64> unit size <integer_cst 0x2a98df6e40 constant invariant 8> align 64 symtab -1729770688 alias set -1 fields <field_decl 0x2a98d96840 vtable> pointer_to_this <pointer_type 0x2a98d97580> chain <type_decl 0x2a98d8bdd0 java.lang.Object>> ignored DI file org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java line 0 size <integer_cst 0x2a98d7ba50 64> unit size <integer_cst 0x2a98d7ba80 constant invariant 8> align 64 offset_align 128 offset <integer_cst 0x2a98d7b570 constant invariant 0> bit offset <integer_cst 0x2a98d7bd50 constant invariant 0> chain <field_decl 0x2a98d9e540 length type <integer_type 0x2a98d872c0 int> readonly decl_1 decl_3 SI file org/gudy/azureus2/core3/peer/impl/PEPieceImpl.java line 0 size <integer_cst 0x2a98d7b900 constant invariant 32> unit size <integer_cst 0x2a98d7b540 constant invariant 4> align 32 offset_align 128 offset <integer_cst 0x2a98d7b570 0> bit offset <integer_cst 0x2a98d7ba50 64> context <record_type 0x2a98dec790 boolean[]> chain <field_decl 0x2a98d9e600 data>>> pointer_to_this <pointer_type 0x2a98dec840>> $4 = void (gdb) p type->common.chain $5 = 0x0 I believe it is frontend's responsibility to create TYPE_STUB_DECLs.
This is to do with Java 1.5 versus Java 1.4. gcj does not yet support Java 1.5. public class poo { Object bar (boolean[] bb) { return bb.clone(); } } ecj generates: 1: invokevirtual <Method java.lang.Object.clone ()java.lang.Object> BEA generates (with -source 1.5): 1: invokevirtual <Method [Z.clone ()java.lang.Object> and with -source 1.4: 1: invokevirtual <Method java.lang.Object.clone ()java.lang.Object> I'm sure gcj will die with other Java 1.5isms too.
Incidentally, if I fix this in the compiler so that we emit a reference to boolean[].clone(), the runtime simply fails, as you'd perhaps expect: Exception in thread "main" java.lang.NoClassDefFoundError: poo at java.lang.Class.initializeClass (libgcj.so.7) at poo.main (poo.java:10) Caused by: java.lang.ClassNotFoundException: boolean[] not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} So the runtime would have to be fixed for this to work in the way that is intended.
Created attachment 124384 [details] .
(In reply to comment #3) > This is to do with Java 1.5 versus Java 1.4. gcj does not yet support Java 1.5. Perhaps this is a bug in the Eclipse compiler then. Compiling with -target 1.4 emits the sequence you're saying should only be for 1.5. The azureus ant file uses -target 1.4. Compiling with -target 1.3 emits what you're saying is acceptable for 1.4. I'm patch the azureus spec file for now. If you're sure about this, I'll file a bug upstream with Eclipse. (It's been a long time since I've seen an ICE in gcj! Thanks for your quick help Andrew)
Offhand I can't think of a reason that calling [Z.clone() would be invalid for a 1.4 runtime. I wrote a little test case and the ecj on my FC4 box generates a call to the array's clone() instead of Object.clone(): public class clone { public static Object x(String[] z) { return z.clone(); } public static void main(String[] args) { System.out.println(x(args)); } } opsy. jcf-dump -c -v clone|grep invokevirtual 1: invokevirtual #17=<Method [Ljava.lang.String;.clone ()java.lang.Object> [...] One (temporary) fix might be to have gcj turns calls to array clone methods to calls to Object.clone. (Though the exceptions differ...)
Oops. When ecj uses defaults, it generates <Method java.lang.Object.clone ()java.lang.Object> with -target 1.4 it generates <Method [Z.clone ()java.lang.Object> I suppose ecj must be generating 1.3 by default. It's a one-line fix to make gcj generate Object.clone: Index: expr.c =================================================================== --- expr.c (revision 110710) +++ expr.c (working copy) @@ -2279,6 +2279,7 @@ superclass chain when we're BC-compiling. */ if (! flag_verify_invocations && method + && ! TYPE_ARRAY_P (self_type) && self_type != DECL_CONTEXT (method)) method = NULL_TREE;
I've CC'd Andrew Overholt. Using "-target 1.3" by default can be bad, at least if Eclipse does this strictly. The difference from 1.3->1.4 was a relaxation in verifier semantics so that 'this$0' could be initialized before the super <init> is called. Without this some code calling an outer class method during initialization can NPE. A strict "1.3" compliance setting (at least in the abstract, I did not check ecj) will generate code that does this -- it has to, because a 1.3 VM will not verify code that sets the this$0 field early.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26192
Should be fixed in gcc-4.1.0-0.27 then.