This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[gcjx] Tree-SSA Operands Processing Problem
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: GCC <gcc at gcc dot gnu dot org>
- Cc: tromey at redhat dot com, amacleod at redhat dot com
- Date: Sun, 08 Jan 2006 21:58:15 +0530
- Subject: [gcjx] Tree-SSA Operands Processing Problem
- Openpgp: url=http://ranjitmathew.hostingzero.com/aa_6C114B8F.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
While trying to debug a long-standing ICE on the
gcjx branch, I have found out that the root cause
of the problem is with the tree-ssa operands processing
code and it still seems to exist on the mainline
(as of revision 109471), though I have traced the code
path in a debugger and actually observed the problem only
on the gcjx branch.
In mainline, the code path starts from
tree-ssa-operands.c:1906 where we have a *local* variable
VAR whose address is passed on to add_stmt_operand() on
the next line:
- ----------------------- 8< -----------------------
1903 /* Add a VUSE for each call-clobbered variable. */
1904 EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, u, bi)
1905 {
1906 tree var = referenced_var (u);
1907 add_stmt_operand (&var, &empty_ann, opf_none |
opf_non_specific);
1908 }
1909
- ----------------------- 8< -----------------------
This function then passes this pointer to append_use() at
line 1634, which seems to just store it as-is in BUILD_USES:
- ----------------------- 8< -----------------------
1572 static void
1573 add_stmt_operand (tree *var_p, stmt_ann_t s_ann, int flags)
1574 {
[...]
1628 if (is_real_op)
1629 {
1630 /* The variable is a GIMPLE register. Add it to real
operands. * /
1631 if (flags & opf_is_def)
1632 append_def (var_p);
1633 else
1634 append_use (var_p);
1635 }
- ----------------------- 8< -----------------------
This seems wrong.
I don't know whether this code path is actually ever
taken on mainline or why it hasn't caused any problems
yet, but on the gcjx branch it causes an ICE while
processing the method "of" of the inner class "UnicodeBlock"
of the class "java.lang.Character"
($GCC_SRC_DIR/libjava/java/lang/Character.java). Specifically,
it ICEs while processing the CALL_EXPR corresponding to
the call to _Jv_ThrowBadArrayIndex() thrown if a subscript
is beyond the limits of an array. The problem occurs when
the stack-slot for the VAR variable referred to earlier
is occupied by the NUM local variable of finalize_ssa_vuses()
and is overwritten when this variable is assigned a value in
this function.
Comments?
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDwT2fYb1hx2wRS48RAr8nAJ90iq5wgQpVeG09vihfwN1x1gvsRACfebPH
3ZjNpJLVJNJZTbWpDEKyxiU=
=NBsE
-----END PGP SIGNATURE-----