Re: java/5537: Error compiling simple bytecode with jsr

Re: java/5537: Error compiling simple bytecode with jsr

[Daniel Bonniot]

The following reply was made to PR java/5537; it has been noted by GNATS.

From: Daniel Bonniot <Daniel.Bonniot@inria.fr>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: Tue, 8 Oct 2002 09:32:33 +0200

 I could reproduce this bug with 
 gcj-3.2 (GCC) 3.2.1 20020912 (Debian prerelease)

Re: java/5537: Error compiling simple bytecode with jsr

[Dara Hazeghi]

The following reply was made to PR java/5537; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, java-prs@gcc.gnu.org
Cc:  
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: Mon, 12 May 2003 12:08:59 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=5537
 
 Hello,
 
 I can confirm that this bug is still present in gcc 3.2, 3.3 branch and  
 mainline (20030511) on i686-linux.
 
 Dara
 

Re: java/5537: Error compiling simple bytecode with jsr

[Daniel Bonniot]

The following reply was made to PR java/5537; it has been noted by GNATS.

From: Daniel Bonniot <Daniel.Bonniot@inria.fr>
To: tromey@redhat.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: Thu, 31 Jan 2002 10:56:09 +0100

 Tom Tromey wrote:
 
 > 
 > I've looked at this.  gcj still rejects the bytecode in this PR.  I
 > think it does so incorrectly; the bytecode looks fine to me and both
 > `java' and `gij' pass it.
 > 
 > How did you generate the bytecode?  
 
 
 The bytecode is the output of Sun/Blackdown javac 1.3.1 on the given A.java
 The error was first found with my own compiler (http://nice.sf.net) that 
 generates java bytecode and now optionally calls gcj on the ouput.
 
 > If you did so with gcj, note that
 > gcj 3.1 no longer generates the same bytecode.  Now the method is
 > simply `return'.  
 
 
 I suppose this is only an optim due to the fact that the finally block 
 is empty. I tried to find the smallest case that triggers the problem.
 
 I have gcj 3.0.3 and it works fine on the source. I haven't tried to 
 make it produce bytecode.
 
  > This doesn't affect the fact that this is a gcj bug.
 
 Right.
 

Re: java/5537: Error compiling simple bytecode with jsr

[Tom Tromey]

The following reply was made to PR java/5537; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Daniel.Bonniot@inria.fr
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/5537: Error compiling simple bytecode with jsr
Date: 30 Jan 2002 16:54:16 -0700

 >>>>> "Daniel" == Daniel Bonniot <Daniel.Bonniot@inria.fr> writes:
 
 Daniel> This case involves calling return in a try/finally block,
 Daniel> and compiling from bytecode.
 
 I've looked at this.  gcj still rejects the bytecode in this PR.  I
 think it does so incorrectly; the bytecode looks fine to me and both
 `java' and `gij' pass it.
 
 How did you generate the bytecode?  If you did so with gcj, note that
 gcj 3.1 no longer generates the same bytecode.  Now the method is
 simply `return'.  (This doesn't affect the fact that this is a gcj
 bug.)
 
 Tom

java/5537: Error compiling simple bytecode with jsr

[Daniel.Bonniot]

>Number:         5537
>Category:       java
>Synopsis:       Error compiling simple bytecode with jsr
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 30 04:26:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Daniel Bonniot
>Release:        3.0.3
>Organization:
>Environment:
Debian package gcj-3.0
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.0.3
>Description:
This case involves calling return in a try/finally block,
and compiling from bytecode.

public class A 
{
  public static void main(String[] args)
  {
    try{
      return;
    }
    finally{
    }
  }
}

gcj compiles correctly from source, but fails on the corresponding
bytecode (attached):
$ gcj A.class
A.java: In class `A':
A.java: In method `A.main(java.lang.String[])':
A.java:6: verification error at PC=8
A.java:6: loading local variable 1 which has unknown type

$ javap -c A.class
Compiled from A.java
public class A extends java.lang.Object {
    public A();
    public static void main(java.lang.String[]);
}

Method A()
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 return

Method void main(java.lang.String[])
   0 jsr 10
   3 return
   4 astore_1
   5 jsr 10
   8 aload_1
   9 athrow
  10 astore_2
  11 ret 2
Exception table:
   from   to  target type
     0     4     4   any
>How-To-Repeat:
gcj A.class
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/x-java-vm; name="A.class"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="A.class"

yv66vgADAC0ADwoAAwAMBwANBwAOAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJU
YWJsZQEABG1haW4BABYoW0xqYXZhL2xhbmcvU3RyaW5nOylWAQAKU291cmNlRmlsZQEABkEuamF2
YQwABAAFAQABQQEAEGphdmEvbGFuZy9PYmplY3QAIQACAAMAAAAAAAIAAQAEAAUAAQAGAAAAHQAB
AAEAAAAFKrcAAbEAAAABAAcAAAAGAAEAAAABAAkACAAJAAEABgAAADEAAQADAAAADagACrFMqAAF
K79NqQIAAQAAAAQABAAAAAEABwAAAAoAAgAAAAYABAAIAAEACgAAAAIACw==