[Bug java/38840] New: GCJ internal compiler error in handle_constant under very specific combination of conditions

[Bug java/38840] New: GCJ internal compiler error in handle_constant under very specific combination of conditions

[nils dot de dot reus at ivm dot vu dot nl]

When compiling a class which assigns the value 1 to a variable of type static
final int, and that class has an annotation with a boolean value being set in
it, and annotation retention policy for the annotation is set RUNTIME, an
internal compiler error occurs in handle_constant.

I tried this on three different compilers, including the latest svn trunk. All
yielded the same error under the same conditions.

Tested with:
  gcj (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu5) (on 64 bit Ubuntu 7.10)
  gcj (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (on 32 bit Ubuntu 8.04 LTS)
  gcj (GCC) 4.4.0 20090113 (experimental) (on 32 bit Ubuntu 8.04 LTS)

I do not know what options the Ubuntu binaries were built with, but I built
from svn using all defaults:

./contrib/download_ecj
./configure --prefix=$HOME/gcc-trunk/20090113
make
make install


I've constructed two files that together demonstrate the effect.

//-------------- TestAnnotation.java -------------------

package nl.vu.ivm.nils.gcj.annotation;

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
public @interface TestAnnotation {
    String eggs() default "";
    int spam() default 0;
    boolean foo() default false;
};
//------------------------------------------------------

//-------------- Test.java -----------------------------

package nl.vu.ivm.nils.gcj.annotation;

import nl.vu.ivm.nils.gcj.annotation.TestAnnotation;

@TestAnnotation(eggs = "yolk", spam = 5, foo = true)
public class Test {
    static final int bar = 1;
};
//------------------------------------------------------



Now here goes.. all well until the third step:

$ gcj -C nl/vu/ivm/nils/gcj/annotation/TestAnnotation.java

$ gcj -C nl/vu/ivm/nils/gcj/annotation/Test.java

$ gcj -c nl/vu/ivm/nils/gcj/annotation/Test.class
In file included from <built-in>:0:
nl/vu/ivm/nils/gcj/annotation/Test.java:0: internal compiler error: in
handle_constant, at java/jcf-parse.c:584
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


Here is again with -v:

$ gcj -v -c nl/vu/ivm/nils/gcj/annotation/Test.class
Using built-in specs.
Reading specs from
/home/nils/gcc-trunk/latest/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/nils/gcc-trunk/latest
Thread model: posix
gcc version 4.4.0 20090113 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c'
'-fbootclasspath=./:/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar'
'-g1' '-shared-libgcc' '-mtune=generic'
COLLECT_GCC_OPTIONS='-v' '-c'
'-fbootclasspath=./:/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar'
'-g1' '-shared-libgcc' '-mtune=generic'
 /home/nils/gcc-trunk/latest/libexec/gcc/i686-pc-linux-gnu/4.4.0/jc1
nl/vu/ivm/nils/gcj/annotation/Test.class -fhash-synchronization
-fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions
-fkeep-inline-functions -quiet -dumpbase Test.class -mtune=generic -auxbase
Test -g1 -version
-fbootclasspath=./:/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar
-faux-classpath /tmp/cccemUCX.zip -o /tmp/ccOYsl8K.s
GNU Java (GCC) version 4.4.0 20090113 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.4.0 20090113 (experimental), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
    /tmp/cccemUCX.zip/ (zip)
    ./ (system)
    /home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar/ (system) (zip)
In file included from <built-in>:0:
nl/vu/ivm/nils/gcj/annotation/Test.java:0: internal compiler error: in
handle_constant, at java/jcf-parse.c:584
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.




What drives me up the walls is that doing *any* of the following will cause
this code to compile, so it must somehow be the combination of these things
that causes the error:

* If I do not set @Retention(RetentionPolicy.RUNTIME), it compiles.

* If I do not assign anything to the boolean field in the annotation (foo in
the example), it compiles.

* If I do not make bar final, it compiles.

* If I assign 0, 2, or 3 to bar, it compiles - just not if I assign 1.


Is this some kind of corner case?


-- 
           Summary: GCJ internal compiler error in handle_constant under
                    very specific combination of conditions
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: nils dot de dot reus at ivm dot vu dot nl
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38840

[Bug java/38840] GCJ internal compiler error in handle_constant under very specific combination of conditions

[nils dot de dot reus at ivm dot vu dot nl]

------- Comment #1 from nils dot de dot reus at ivm dot vu dot nl  2009-01-14 20:44 -------

It is a bit further removed from the real life situation I am dealing with, but
to make testing easier I've moved it all into one file so you don't need to
bother with importing or package structure.


// ------------------------- Test.java -------------------------------
import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@interface TestAnnotation {
    String eggs() default "";
    int spam() default 0;
    boolean foo() default false;
};

@TestAnnotation(eggs = "yolk", spam = 5, foo = true)
public class Test {
    static final int bar = 1;
};
// -------------------------------------------------------------------


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38840