This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: fix for jsr routines that do not have returns
- From: Tom Tromey <tromey at redhat dot com>
- To: Dan <d2walter at Oakland dot edu>
- Cc: java-patches at gcc dot gnu dot org
- Date: 02 Dec 2001 13:56:47 -0700
- Subject: Re: fix for jsr routines that do not have returns
- References: <Pine.OSF.4.21.0112021423500.20293-100000@saturn3.acs.oakland.edu>
- Reply-to: tromey at redhat dot com
>>>>> "Dan" == Dan <d2walter@Oakland.edu> writes:
Dan> void fail(){
Dan> try {
Dan> test();
Dan> } finally {
Dan> throw new RuntimeException("test exceptions");
Dan> }
Dan> }
For this, see also PR 4766.
`gcj -C' generates invalid bytecode from this source (it generates a
`goto' that is out of range).
Dan> When this is compiled with Sun's javac it produces .class files
Dan> that fail to verify or to compile because the jsr does not havee
Dan> a ret. I modified gcj to treat such jsr's as gotos.
With my javac this doesn't happen -- no jsr is generated.
What version of javac are you using?
Could you send the output of `jcf-dump -c' on the javac-generated code?
I'd like to see it. In fact, could you run the appended program
through your javac and then send the whole .class file (suitably
encoded to protect it from email)? I'd really appreciate that.
Thanks,
Tom
import java.math.*;
public class t
{
public void fail ()
{
try
{
System.out.println ("foo");
}
finally
{
throw new RuntimeException ("hi!");
}
}
public static void main (String[] args)
{
}
}