wrong alias-analysis and strange x86-code
Wed Oct 25 08:52:00 GMT 2000
On Tue, 24 Oct 2000, Volker Barthelmann wrote:
> First, gcc 2.95 seems to do overly optimistic type-based alias-analysis. In
> the example attached to this mail it apparently assumes that an expression
> p[x] cannot alias certain objects and generates wrong code.
> int x,*p=&x;
> int i=0;
This happens because expand_expr, case INDIRECT_REF, assumes that if the
address it's dereferencing is a PLUS, the object must be a structure, so it
sets the MEM_IN_STRUCT flag on the MEM for p[i]. This causes cse to substitute
1 for x in the call to printf.
It can be fixed by the patch below. The code in question came in through a
merge from the gcc2 sources; I can't tell exactly when the change was made
there because anoncvs.gnu.org won't talk to me and there doesn't appear to be
a corresponding ChangeLog entry.
The code in question seems to have disappeared in current CVS (no trace of it
in set_mem_attributes), so there's probably nothing to worry about.
* expr.c (expand_expr, case INDIRECT_REF): If the address is a
PLUS, that does not prove the object is in a structure.
RCS file: /cvs/gcc/egcs/gcc/expr.c,v
retrieving revision 188.8.131.52
diff -u -p -r184.108.40.206 expr.c
--- expr.c 1999/06/30 22:59:55 220.127.116.11
+++ expr.c 2000/10/25 15:45:01
@@ -6264,10 +6264,7 @@ expand_expr (exp, target, tmode, modifie
temp = gen_rtx_MEM (mode, op0);
/* If address was computed by addition,
mark this as an element of an aggregate. */
- if (TREE_CODE (exp1) == PLUS_EXPR
- || (TREE_CODE (exp1) == SAVE_EXPR
- && TREE_CODE (TREE_OPERAND (exp1, 0)) == PLUS_EXPR)
- || AGGREGATE_TYPE_P (TREE_TYPE (exp))
+ if (AGGREGATE_TYPE_P (TREE_TYPE (exp))
|| (TREE_CODE (exp1) == ADDR_EXPR
&& (exp2 = TREE_OPERAND (exp1, 0))
&& AGGREGATE_TYPE_P (TREE_TYPE (exp2))))
More information about the Gcc-patches