Re: Your June 7 change to expand_expr

[Jim Wilson <wilson at cygnus dot com>]

	But now I wonder: can't we currently get this in C with pointers?  Don't
	we have a bug with:

	void
	sub1 (int *q)
	{
	  int arr1[5], arr2[5];
	  int *p = &arr1[4];

	  strcpy ((char *) arr1, (char *) q);
	  *p = 55;
	  strcpy ((char *) arr2, (char *) arr1);
          foo (arr2);
	}

	if strcpy is the builtin?  Isn't there the risk of scheduling the assignment
	to *p after a read from arr1 in the second strcpy just like happened in the
	Ada case?

This is essentially the same as John Carr's testcase.

If we ignore optimization, then there is no problem here.  The aliasing rule
says that a reference to a scalar at a non-varying address will never alias a
reference to an aggregate at a varying address.  *p is a reference to a scalar
with a varying address.  The aliasing rule will not be triggered for this, and
hence there is no chance of getting the wrong answer from the aliasing code.

However, this testcase could fail is cse rewrites the address used in the
*p access.  *p is obviously a varying reference.  However, p was set to the
address of a stack slot, which is a non-varying address.  If cse makes this
substitution, then the varying address check in the aliasing code will give
the wrong answer.

If this is indeed the problem that you ran into with Ada REFERENCE_TYPEs,
then the correct solution is to save the varying/non-varying info in a second
bit, rather than trying to determine it from a MEM's address.  This is what
I just mentioned in my last message.

This bug incidentally has been a known bug for a very long time.  I have
discussed this bug with you before circa 1992/1993.  I know I sent mail to
gcc2 in 1993 about this problem.  The problem was so rare, and so inconvenient
to fix though, that no one ever got around to trying to fix it.  It looks like
we can't ignore it anymore though if this is the problem that your Ada
example triggered.

Jim