Bug 18931

What target is this on? i686-pc-linux?
I cannot reproduce this on 20041204 on powerpc-darwin.

Yes, this is i686-linux.  I'll update to a more recent snapshot and see if I can
reproduce.

I got this to fail with yesterday's cvs head.
Removing the "-O2" is a workaround.

Bumping priority because this is possibly a front end bug that breaks many programs/

Subject: Bug 18931

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	aph@gcc.gnu.org	2004-12-17 15:09:12

Modified files:
	gcc/java       : ChangeLog convert.h expr.c typeck.c 

Log message:
	2004-12-17  Andrew Haley  <aph@redhat.com>
	
	PR java/18931
	* typeck.c (convert): Use a CONVERT_EXPR when converting to
	BOOLEAN_TYPE or CHAR_TYPE.
	(convert_to_boolean, convert_to_char) : Remove.
	* convert.h (convert_to_boolean, convert_to_char) : Remove.
	* expr.c (expand_load_internal): Do type conversion if type is not
	as required.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1522&r2=1.1523
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/convert.h.diff?cvsroot=gcc&r1=1.6&r2=1.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.214&r2=1.215
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/typeck.c.diff?cvsroot=gcc&r1=1.73&r2=1.74

Fixed on the mainline.

Using Jakub's gcc4 RPMs from Fedora rawhide (on Fedora Core 3), I'm getting:

gcj4 -O2 -fPIC -fjni -findirect-dispatch -shared -o jsch-0.1.17.so \
jsch-0.1.17.jar

com/jcraft/jsch/ChannelSftp.java: In method
'com.jcraft.jsch.ChannelSftp.ls(java.lang.String)':
com/jcraft/jsch/ChannelSftp.java:0: internal compiler error: in
remove_unreachable_regions, at except.c:694

This does not happen with no -O flag.

gcj4 --version:
gcj4 (GCC) 4.0.0 20041228 (Red Hat 4.0.0-0.17)
target:  i686-pc-linux

File:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.cvs.ssh2/jsch-0.1.17.jar

A similar error happens with jsch-0.1.16.jar.

I narrowed this down to a small test case. The following code will cause the
crash when compiled to bytecode using Sun's javac 1.5.0 (but not when
byte-compiled with gcj or ecj).

public class PR18931 {

  public int getByte() 
  {
    return 1;
  }

  public void ls(String p) throws Exception{
    try{
      p.toString();

      int type=getByte();

      if(type!=100){
	throw new Exception("");
      }
      if(type==100) return;
      throw new Error();
    }
    catch(Exception e){
      throw new Exception("");
    }
  }
}

It occurs to me that we don't have any way to do regression tests for bytecode
compilation failures with bytecode produced by other compilers.

Created attachment 7880 [details]
.class file to reproduce failure

I suppose we could check in .class files.
That is mildly painful, if we ever want to change things.
I've occasionally wished we distributed our own jasmin-like
program for these situations.  This sort of thing would be
helpful for testing the verifier as well.

There is at least one test case that includes a binary blob
that it uses to make a new class on the fly.  That's probably
worse than committing a .class file though.

Hmm, again this works for me on ppc-darwin, I don't know why.

It looks like my patch of 2004-12-17 fixes the original bug, but there is a
separate bug triggered by a different test case.  It shouldn't be attached to
this PR.

Please check that my patch really did fix the original bug and close this PR. 
Please open another PR against the new test case.

Original bug verified fixed.  New PR filed as requested:  PR19505.