wrong alias-analysis and strange x86-code

[Bernd Schmidt]

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;
> 
> main()
> {
>  int i=0;
>  x=1;
>  p[i]=2;
>  printf("%d\n",x);
> }

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.


Bernd

	* expr.c (expand_expr, case INDIRECT_REF): If the address is a
	PLUS, that does not prove the object is in a structure.

Index: expr.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/expr.c,v
retrieving revision 1.144.4.3
diff -u -p -r1.144.4.3 expr.c
--- expr.c	1999/06/30 22:59:55	1.144.4.3
+++ 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))))