Hi,
On Fri, Nov 07, 2008 at 01:05:43PM -0500, DJ Delorie wrote:
>
> Note that you'll have to build (and install, of course) a
> cross-binutils first, then build a cross-gcc (libgcc will fail to
> build), then cross-build and install newlib, then build cross-gcc
> again (it will work this time) and install it.
>
Sounds rather complicated, I guess will want to do something like that
one day. However, certainly not today. I thought about the PR37861
again, about associated PR31982 (big thanks to Andrew Pinski who
pointed me to it) and about the regression you discovered and came to
these conclusions:
1. The regression is most probably "caused" by my patch but the gimple
it leads to is (as far as I can tell) valid and so the target may
bump into this problem at some other time. I am sorry but I do not
have the knowledge to be bale to help with fixing it.
2. I might actually be less restrictive in my approach. I've come up
with the following patch which undoes my previous one and adds a
different restriction which also fixes PR37861, does not break
PR31982 and should fix the particular test-case you see regressing
(however, it is possible that the bug might be triggered in some
other way, regardless of my patches). On the other hand, it is a
bit clumsy and not very systematic :-( I am currently bootstrapping
and testing it (on x86_64) and will send it to gcc-patches for
discussion/approval on Monday (or Tuesday) if there are no new
regressions.
If you get a chance, can you please test it for me on the affected
arch?
Thanks,
Martin
2008-11-07 Martin Jambor <[EMAIL PROTECTED]>
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check
for INDIRECT_REFs.
(forward_propagate_addr_into_variable_array_index): Check that the
offset is not computed from a MULT_EXPR, use is_gimple_assign rather
than the gimple code directly.
Index: gcc/tree-ssa-forwprop.c
===================================================================
--- gcc/tree-ssa-forwprop.c (revision 141673)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -613,19 +613,27 @@ forward_propagate_addr_into_variable_arr
tree index;
gimple offset_def, use_stmt = gsi_stmt (*use_stmt_gsi);
- /* Try to find an expression for a proper index. This is either
- a multiplication expression by the element size or just the
- ssa name we came along in case the element size is one. */
+ /* Get the offset's defining statement. */
+ offset_def = SSA_NAME_DEF_STMT (offset);
+
+ /* Try to find an expression for a proper index. This is either a
+ multiplication expression by the element size or just the ssa name we came
+ along in case the element size is one. In that case, however, we do not
+ allow multiplications because they can be computing index to a higher
+ level dimension (PR 37861). */
if (integer_onep (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (def_rhs)))))
- index = offset;
- else
{
- /* Get the offset's defining statement. */
- offset_def = SSA_NAME_DEF_STMT (offset);
+ if (is_gimple_assign (offset_def)
+ && gimple_assign_rhs_code (offset_def) == MULT_EXPR)
+ return false;
+ index = offset;
+ }
+ else
+ {
/* The statement which defines OFFSET before type conversion
must be a simple GIMPLE_ASSIGN. */
- if (gimple_code (offset_def) != GIMPLE_ASSIGN)
+ if (!is_gimple_assign (offset_def))
return false;
/* The RHS of the statement which defines OFFSET must be a
@@ -802,9 +810,6 @@ forward_propagate_addr_expr_1 (tree name
array_ref = TREE_OPERAND (def_rhs, 0);
if (TREE_CODE (array_ref) != ARRAY_REF
|| TREE_CODE (TREE_TYPE (TREE_OPERAND (array_ref, 0))) != ARRAY_TYPE
- /* Avoid accessing hidden multidimensional arrays in this way or VRP
- might give out bogus warnings (see PR 37861) */
- || TREE_CODE (TREE_OPERAND (array_ref, 0)) == INDIRECT_REF
|| !integer_zerop (TREE_OPERAND (array_ref, 1)))
return false;
