Hello,
> 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.
this can never happen. Note that is_real_op = is_gimple_reg (var), and
a call clobbered variable can never satisfy is_gimple_reg. Most likely
you forget to set TREE_ADDRESSABLE for this variable. Or it gets to
call_clobbered_vars wrongly.
Zdenek
> 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-----
>
