This is the mail archive of the gcc-patches@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]

[PATCH][C++] Fix PR43075, really remove all zero-sized stores


This is an attempt (*sigh*) to fix PR43075 by making sure we remove
zero-sized assignments that are not seen as zero-size from the IL
during genericization.  We already do so for MODIFY_EXPR, but as
PR43075 shows we may have INIT_EXPRs of this kind as well.

Now - simply adding || TREE_CODE (stmt) == INIT_EXPR break a shitload
of code because there's funny things going on all over the place
I have no idea of.

Thus, the following crude patch emerged from incrementally adding
exceptions .... which now leads me to the question how
cp_expr_size can say integer_zero_node to sth initialized from a
AGGR_INIT_EXPR with obviously non-zero-sized elements.

Bah.  Maybe the case in PR43075 should have used a MODIFY_EXPR
instead of an INIT_EXPR?

Jason, maybe you have more clue about the workings of cp_expr_size
and INIT_EXPR - the gimplifier treats them the same as MODIFY_EXPR.

Thus, help!  (This one passes dg.exp at least, full bootstrap
and regtest running)

Thanks,
Richard.

2010-02-15  Richard Guenther  <rguenther@suse.de>

	PR c++/43075
	* cp-gimplify.c (cp_genericize_r): Also remove zero-sized
	INIT_EXPR.

Index: gcc/cp/cp-gimplify.c
===================================================================
*** gcc/cp/cp-gimplify.c	(revision 156769)
--- gcc/cp/cp-gimplify.c	(working copy)
*************** cp_genericize_r (tree *stmt_p, int *walk
*** 689,694 ****
--- 689,695 ----
    tree stmt = *stmt_p;
    struct cp_genericize_data *wtd = (struct cp_genericize_data *) data;
    struct pointer_set_t *p_set = wtd->p_set;
+   tree tem;
  
    if (is_invisiref_parm (stmt)
        /* Don't dereference parms in a thunk, pass the references through. */
*************** cp_genericize_r (tree *stmt_p, int *walk
*** 866,874 ****
        *walk_subtrees = 0;
      }
  
!   else if (TREE_CODE (stmt) == MODIFY_EXPR
! 	   && (integer_zerop (cp_expr_size (TREE_OPERAND (stmt, 0)))
! 	       || integer_zerop (cp_expr_size (TREE_OPERAND (stmt, 1)))))
      {
        *stmt_p = build2 (COMPOUND_EXPR, TREE_TYPE (stmt),
  			TREE_OPERAND (stmt, 0),
--- 867,883 ----
        *walk_subtrees = 0;
      }
  
!   /* Make sure to drop zero-size assignments that only the frontend
!      can tell apart from single-byte assignments.  */
!   else if ((TREE_CODE (stmt) == MODIFY_EXPR
! 	    || (TREE_CODE (stmt) == INIT_EXPR
! 		&& TREE_CODE (TREE_OPERAND (stmt, 1)) != TARGET_EXPR
! 		&& TREE_CODE (TREE_OPERAND (stmt, 1)) != AGGR_INIT_EXPR
! 		&& TREE_CODE (TREE_OPERAND (stmt, 1)) != ERROR_MARK
! 		&& !TREE_ADDRESSABLE (TREE_TYPE (TREE_OPERAND (stmt, 1)))))
! 	   && TREE_CODE (TREE_OPERAND (stmt, 0)) != RESULT_DECL
! 	   && (tem = cp_expr_size (TREE_OPERAND (stmt, 0)))
! 	   && integer_zerop (tem))
      {
        *stmt_p = build2 (COMPOUND_EXPR, TREE_TYPE (stmt),
  			TREE_OPERAND (stmt, 0),


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