Bug 19505 - [4.0 Regression] java bytecode to native ICE in remove_unreachable_regions
[4.0 Regression] java bytecode to native ICE in remove_unreachable_regions
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: tree-optimization
4.0.0
: P5 normal
: 4.0.4
Assigned To: Andrew Haley
http://gcc.gnu.org/ml/gcc-patches/200...
: ice-on-valid-code, patch
: 20591 (view as bug list)
Depends on:
Blocks: 17574 28067 28090
  Show dependency treegraph
 
Reported: 2005-01-18 14:50 UTC by Andrew Overholt
Modified: 2006-07-18 22:59 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-07-11 16:16:04


Attachments
Failing class file test case (552 bytes, application/octet-stream)
2005-01-25 15:25 UTC, Bryce McKinlay
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Overholt 2005-01-18 14:50:02 UTC
As per final comment in PR18931, I'm opening a new PR.  For additional comments
and a test case, see comments >= 2005-01-05 23:53 in PR18931.

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.
Comment 1 Andrew Pinski 2005-01-24 16:34:21 UTC
Just a little more information.
changing "s = redirect_edge_succ_nodup (e, dest);" to a "return false;" in remove_forwarder_block 
makes this pass so this is a tree optimization problem.  Basically what is happening is that we are 
forwarding two eh regions to one bb which is just wrong.  A better check in remove_forwarder_block is 
needed to better test for this case.  Note this only happens with the java front-end because the java 
front-end produces a goto from two catches without any code before it (which is not wrong).


Making this block 17574 which is the meta-bug for "java" bugs which should be fixed before 4.0 (or are 
just regressions in 4.0).
Comment 2 Bryce McKinlay 2005-01-25 15:12:24 UTC
Here's a test case for this bug, copied from PR18931. This will fail when
compiling from bytecode produced by Sun's javac, but not from bytecode produced
by gcj or ecj. 

public class PR19505 {

  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 Exception();
    }
    catch(Exception e){
      throw new Exception("");
    }
  }
}

Comment 3 Bryce McKinlay 2005-01-25 15:25:02 UTC
Created attachment 8061 [details]
Failing class file test case

Compile this class file with:

gcj -c -O PR19505.class

to reproduce the error.
Comment 4 Kazu Hirata 2005-01-25 20:47:42 UTC
(In reply to comment #1)
> Just a little more information.
> changing "s = redirect_edge_succ_nodup (e, dest);" to a "return false;" in
remove_forwarder_block 
> makes this pass so this is a tree optimization problem.  Basically what is
happening is that we are 
> forwarding two eh regions to one bb which is just wrong.  A better check in
remove_forwarder_block is 
> needed to better test for this case.  Note this only happens with the java
front-end because the java 
> front-end produces a goto from two catches without any code before it (which
is not wrong).
> 
> 
> Making this block 17574 which is the meta-bug for "java" bugs which should be
fixed before 4.0 (or are 
> just regressions in 4.0).
Comment 5 Kazu Hirata 2005-01-25 21:38:39 UTC
I cannot reproduce this.  How frustrating!

CCing Zdenek because he wrote remove_forwarder_block.
Comment 6 Tom Tromey 2005-01-25 23:13:17 UTC
I updated and rebuilt gcc and I was able to see this
with the .class file that is attached to the PR.

opsy. gcj -O2 -fPIC -fjni -findirect-dispatch -c PR19505.class
PR19505.java: In class 'PR19505':
PR19505.java: In method 'PR19505.ls(java.lang.String)':
PR19505.java:0: internal compiler error: in remove_unreachable_regions, at
except.c:694
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
opsy. gcj --version
gcj (GCC) 4.0.0 20050125 (experimental)
[...]

This is x86 Fedora Core 2.
Comment 7 Andrew Pinski 2005-03-22 16:55:47 UTC
*** Bug 20591 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2005-09-20 22:08:07 UTC
Still happens with the mainline: "4.1.0 20050919".
Comment 9 Andrew Pinski 2005-09-20 22:19:32 UTC
Note at -O1 I cannot reproduce it but at -O2 I could.
Comment 10 Andrew Pinski 2005-09-24 21:31:17 UTC
The problem shows up only in .final_cleanup.
Before:
Eh tree:
   4 catch tree_label:<L8>
   3 try
   2 catch tree_label:<L5>
   1 try

After:
   4 catch tree_label:*LJpc=2041
   3 try
   2 catch tree_label:*LJpc=2041
   1 try

Comment 11 Andrew Pinski 2005-09-24 21:31:47 UTC
One more thing, is that this happens only at -O2 and above.
Comment 12 Andrew Pinski 2005-09-24 23:08:14 UTC
I have a patch which dects this earlier and will post it soon.
Comment 13 Andrew Pinski 2005-09-24 23:32:07 UTC
I have a very simple work around.  If we could get the eh region from a label/bb, it would make it 
easier.
Comment 14 Andrew Pinski 2005-09-25 16:00:55 UTC
The patch is:
Index: tree-cfgcleanup.c
===============================================================
====
RCS file: /cvs/gcc/gcc/gcc/tree-cfgcleanup.c,v
retrieving revision 2.7
diff -u -p -r2.7 tree-cfgcleanup.c
--- tree-cfgcleanup.c	19 Aug 2005 18:52:55 -0000	2.7
+++ tree-cfgcleanup.c	24 Sep 2005 23:30:54 -0000
@@ -392,7 +392,18 @@ remove_forwarder_block (basic_block bb, 
 	    return false;
 	}
     }
-
+  /* Check to make sure that we can remove a forwarder block for eh edges.  */
+  FOR_EACH_EDGE (e, ei, bb->preds)
+    {
+      /* This check is too strong, we should also be checking eh regions
+         but this is much harder.  */
+      if (e->flags & EDGE_EH)
+        {
+	  if (!single_pred_p (dest))
+	    return false;
+	}
+    }
+  
   /* Redirect the edges.  */
   for (ei = ei_start (bb->preds); (e = ei_safe_edge (ei)); )
     {


Which I will post after testing.
I posted the checking patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01559.html
Comment 15 Andrew Haley 2005-09-27 17:35:49 UTC
We also need http://gcc.gnu.org/ml/java/2005-09/msg00053.html.
Comment 16 Andrew Haley 2005-09-27 17:38:24 UTC
Forget that last comment.  Wrong PR.
Comment 17 Andrew Pinski 2005-10-02 18:52:00 UTC
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00048.html
Comment 18 Andrew Pinski 2005-10-23 00:03:47 UTC
No longer working on this.  Sorry, if someone wants to take my patch and update, that is ok with me.
Comment 19 Mark Mitchell 2005-10-31 02:28:21 UTC
Marked as P5 as Java is not release-critical.  If this can be shown to occur with a non-Java test case, please Cc: me on this PR, so that I can adjust accordingly.
Comment 20 Mark Mitchell 2006-05-25 02:35:41 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 21 Anthony Green 2006-07-08 19:24:01 UTC
I've hit this bug while rebuilding azureus for FC6 (bytecode produced by ecj).  I hope we can get a fix in the FC6 gcc 4.1.1 fork.  I'll try compiling without optimization for now.
Comment 22 Anthony Green 2006-07-08 20:26:13 UTC
For the azureus test case, grab:
http://people.redhat.com/~green/FE/devel/azureus-2.4.0.3-0.20060702cvs_2.src.rpm

Edit the spec file to remove RPM_OPT_FLAGS="-O0" from this line:
RPM_OPT_FLAGS="-O0" aot-compile-rpm

This SRPM only builds in FC rawhide with the following packages or newer installed:
 http://people.redhat.com/fitzsim/bouncycastle-1.33-1.src.rpm
 http://people.redhat.com/fitzsim/java-1.4.2-gcj-compat-1.4.2.0-40jpp_88rh.src.rpm
Comment 23 Andrew Haley 2006-07-17 13:14:47 UTC
Subject: Bug 19505

Author: aph
Date: Mon Jul 17 13:14:38 2006
New Revision: 115518

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115518
Log:
2006-07-13  Andrew Haley  <aph@redhat.com>

        PR tree-optimization/19505
        * tree-cfgcleanup.c (tree_forwarder_block_p): If we have an EH
        edge leaving this block, make sure that the destination of this
        block has only one predecessor.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-cfgcleanup.c

Comment 24 Andrew Haley 2006-07-18 09:01:05 UTC
Subject: Bug 19505

Author: aph
Date: Tue Jul 18 09:00:29 2006
New Revision: 115547

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115547
Log:
2006-07-18  Andrew Haley  <aph@redhat.com>

        PR tree-optimization/19505
        * tree-cfgcleanup.c (tree_forwarder_block_p): If we have an EH
        edge leaving this block, make sure that the destination of this
        block has only one predecessor.


Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/tree-cfgcleanup.c

Comment 25 Andrew Pinski 2006-07-18 09:06:42 UTC
Fixed on the 4.1 branch also now.
Comment 26 Andrew Haley 2006-07-18 15:07:56 UTC
Subject: Bug 19505

Author: aph
Date: Tue Jul 18 15:07:48 2006
New Revision: 115554

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115554
Log:
2006-07-13  Andrew Haley  <aph@redhat.com>

        PR tree-optimization/19505
        * tree-cfgcleanup.c (tree_forwarder_block_p): If we have an EH
        edge leaving this block, make sure that the destination of this
        block has only one predecessor.


Modified:
    branches/gcj-eclipse/gcc/ChangeLog
    branches/gcj-eclipse/gcc/tree-cfgcleanup.c

Comment 27 Andrew Pinski 2006-07-18 22:59:38 UTC
Fixed.