This is the mail archive of the
mailing list for the GCC project.
[patch] expr.c: Don't request a value to expand_assignment.
- From: Kazu Hirata <kazu at cs dot umass dot edu>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sat, 16 Oct 2004 08:32:24 -0400 (EDT)
- Subject: [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?
2004-10-15 Kazu Hirata <email@example.com>
* expr.c (expand_expr_real_1) [MODIFY_EXPR]: Don't request a
value to expand_assignment.
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
+ if (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 @@
- temp = expand_assignment (lhs, rhs, ! ignore);
+ temp = expand_assignment (lhs, rhs, 0);