This is the mail archive of the 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] expr.c: Don't request a value to expand_assignment.


Attached is a patch to not request a value to expand_assignment when
expanding a MODIFY_EXPR.

As far as I know, the tree-ssa infrastructure does not generate tree
that requests a value of an assignment (e.g. a = b = c;) regardless of
whether optimizing or not.

This is the only place that requests a value to expand_assignment.
Once this patch is applied, we can clean up expand_assignment so that
it won't have to bother returning a value.

Tested on i686-pc-linux-gnu.  OK to apply?

Kazu Hirata

2004-10-15  Kazu Hirata  <>

	* expr.c (expand_expr_real_1) [MODIFY_EXPR]: Don't request a
	value to expand_assignment.

Index: expr.c
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.726
diff -u -r1.726 expr.c
--- expr.c	3 Oct 2004 22:50:18 -0000	1.726
+++ expr.c	15 Oct 2004 21:58:23 -0000
@@ -8077,6 +8090,8 @@
 	temp = 0;
+	gcc_assert (ignore);
 	/* Check for |= or &= of a bitfield of size one into another bitfield
 	   of size 1.  In this case, (unless we need the result of the
 	   assignment) we can do this more efficiently with a
@@ -8085,8 +8100,7 @@
 	   ??? At this point, we can't get a BIT_FIELD_REF here.  But if
 	   things change so we do, this code should be enhanced to
 	   support it.  */
-	if (ignore
-	    && TREE_CODE (lhs) == COMPONENT_REF
 	    && (TREE_CODE (rhs) == BIT_IOR_EXPR
 		|| TREE_CODE (rhs) == BIT_AND_EXPR)
 	    && TREE_OPERAND (rhs, 0) == lhs
@@ -8109,7 +8123,7 @@
 	    return const0_rtx;
-	temp = expand_assignment (lhs, rhs, ! ignore);
+	temp = expand_assignment (lhs, rhs, 0);
 	return temp;

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