Bug 180418

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.