This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [dj@delorie.com: Results for 4.4.0 20081106 (experimental) [trunk revision 141636] (GCC) testsuite on m32c-unknown-elf]


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  <mjambor@suse.cz>

	* 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;
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]