Re: Your June 7 change to expand_expr

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    It seems wrong to assume that an dereference of a REFERENCE_TYPE is
    always an aggregate reference.  Can't we have a REFERENCE_TYPE that
    refers to a non-aggregate?

Sure, but the point is that you can't possibly know which it is in any
individual case, and setting it to be an aggregate is the direction
less likely to cause bad code.

I admit to being totally confused at the moment as to why the same
problem doesn't occur with pointers, but the whole MEM_IN_STRUCT_P
stuff is something I don't understand all that well.

    Seems to me it should depend on the underlying type.

I don't follow.  In all the relevant cases, both the pointer and the
reference type would be pointing to an integer.


Here's how this came up: Ada has the concept of a renaming, where you
rename one object to have another name.  So you can have

	type arr is array (1..10) of integer;
	foo: arr;
	bar: integer renames arr(5);

What the Ada front end originally did was to treat "bar" as a macro
for "arr(5)".  The problem with this is that then it doesn't exist in
the debugging output, so people can't display it and they complained.

The most straightforward fix is to make "bar" what would be

	int *bar = &arr[5];

in C.

The problem there is that then it has the wrong type to the debugger;
it looks like a pointer.  So what was done was to use a REFERENCE_TYPE
in the cases when the front end needed to do make an implicit address
operation and teach the debugger to know that means it needs to do an
implicit dereference.  That worked well.

The test case for this change was then the above definition with some
other code copying the entire "arr".  It got mis-scheduled.

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?