This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug java/16113] [3.5 Regression] ICE: Segmentation fault when compiling bytecode with debugging info and try/catch
- From: "rmathew at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Jun 2004 11:39:32 -0000
- Subject: [Bug java/16113] [3.5 Regression] ICE: Segmentation fault when compiling bytecode with debugging info and try/catch
- References: <20040621125932.16113.bonniot@users.sf.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From rmathew at gcc dot gnu dot org 2004-06-22 11:39 -------
(In reply to comment #5)
> This might be as simple as removing the call to expand_end_bindings() from
> force_poplevels().
Indeed! I removed this call, rebuilt libgcj and reran the testsuite (including
Jacks) and there were no regressions (only the two "err6" failures that are
anyway seen on mainline today).
FWIW, here's the "expand_*" usage in the GCJ front end:
------------------------------ 8< ------------------------------
expr.c: expand_eh_region_start ();
expr.c: expand_start_all_catch ();
expr.c: expand_start_catch (prepare_eh_table_type (type));
expr.c: expand_end_catch ();
expr.c: expand_end_all_catch ();
expr.c: expand_decl (array_decl);
expr.c: expand_decl (pushdecl (local));
expr.c: tmp = expand_assignment (array_decl,
expr.c: expand_assignment (build (COMPONENT_REF, TREE_TYPE (data_fld),
class.c: expand_function_start (init_decl, 0);
resource.c: expand_function_start (init_decl, 0);
class.c: expand_function_end ();
resource.c: expand_function_end ();
expr.c: expand_goto (target_label);
expr.c: expand_goto (target_label);
expr.c: expand_expr_stmt (TREE_OPERAND (exp, 0));
expr.c: expand_expr_stmt (TREE_OPERAND (current, 0));
expr.c: expand_expr_stmt (build (MODIFY_EXPR, boolean_type_node,
expr.c: expand_end_bindings (getdecls (), 1, 0);
expr.c: expand_decl (array_decl);
expr.c: expand_decl (pushdecl (local));
------------------------------ 8< ------------------------------
Should these be removed/replaced as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16113