This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: CALL_EXPR representation part 3/9 (middle-end stuff)
Diego Novillo wrote:
Sandra Loosemore wrote on 02/12/07 14:20:
Index: gcc/tree-ssa.c
===================================================================
*** gcc/tree-ssa.c (revision 121705)
--- gcc/tree-ssa.c (working copy)
*************** tree_ssa_useless_type_conversion (tree e
*** 955,962 ****
|| TREE_CODE (expr) == VIEW_CONVERT_EXPR
|| TREE_CODE (expr) == NON_LVALUE_EXPR)
return tree_ssa_useless_type_conversion_1 (TREE_TYPE (expr),
! TREE_TYPE (TREE_OPERAND (expr,
! 0)));
return false;
--- 955,962 ----
|| TREE_CODE (expr) == VIEW_CONVERT_EXPR
|| TREE_CODE (expr) == NON_LVALUE_EXPR)
return tree_ssa_useless_type_conversion_1 (TREE_TYPE (expr),
! GENERIC_TREE_TYPE (TREE_OPERAND (expr,
! 0)));
Why GENERIC_TREE_TYPE here? You shouldn't be getting a gimple-stmt
here.
Maybe I shouldn't be getting one, but in fact I *did* run into an ICE
on this when I was testing this last week. :-) IIRC, it happened
when making java/lang/reflect/.libs/natMethod.o.
Something's not right. This should only trigger for expression codes
that should have a valid TREE_TYPE, so that TREE_OPERAND (expr, 0)
should most definitely have a non-NULL type. You may be papering over
some bug here.
I've spent several more hours looking at this issue, and I've become convinced
that your assertion that "You shouldn't be getting a gimple-stmt here" is incorrect.
The ICE is happening when compiling libjava/java/lang/reflect/natMethod.cc, at
line 633, which is a call to memcpy. It's basically using memcpy to copy a long
integer, e.g., memcpy (dest, &i, sizeof(i)) -- which is one of the cases that
builtin_memcpy optimizes to a simple assignment. The problematic call to
tree_ssa_useless_type_conversion() is happening when the gimplifier is invoked
via cp_genericize(), but folding of calls to builtins happens long before then;
in most cases, we try to fold as a preliminary to even constructing a CALL_EXPR.
For builtin_memcpy, the folding is performed by fold_builtin_memory_op, in
builtins.c. And, what's it doing? Yup, it's explicitly building and returning
a GIMPLE_MODIFY_STMT. I notice that a couple of the other folders
(fold_builtin_memset, do_mpfr_sincos) are also explicitly constructing
GIMPLE_MODIFY_STMTs. This is in the unmodified mainline version of builtins.c;
so if this is a bug, it's independent of the changes associated with the
CALL_EXPR work, and given the difficulty of keeping up with bit rot in such a
large patch, I'm not inclined to want to hold off on committing it while we
figure out how to solve this other problem, especially since my patch above does
fix the ICE when building the compiler, and the test suites run without
regression. OK?
We've now fixed all the other items you noted in your review. My plan is to do
one more round of testing tonight, and resubmit the patch tomorrow.
-Sandra