Re: Your June 7 change to expand_expr

[Jeffrey A Law <law at cygnus dot com>]

  In message <9807010310.AA15076@vlsi1.ultra.nyu.edu>you write:
  >     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 disagree that setting MEM_IN_STRUCT_P is less likely to generate
bad code.

MEM_IN_STRUCT_P only comes into play when memory references have
*different* values for MEM_IN_STRUCT_P *and* when the reference
with MEM_IN_STRUCT_P is a varying address and the reference w/o
MEM_IN_STRUCT_P is a non-varying address.

And since most references to do not have MEM_IN_STRUCT_P set, you've
*increased* the number of memory references that you do not conflict
with -- which seems less safe to me.


  > 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.
But is the integer these things point to part of an aggregate?  That
is the key question you have to answer before setting MEM_IN_STRUCT_P.


  > 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.
Right.

  > The most straightforward fix is to make "bar" what would be
  > 
  > 	int *bar = &arr[5];
  > 
  > in C.
OK

  > 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.
Right.  Presumably setting MEM_IN_STRUCT_P is OK and correct for your
test, but I'm not sure it's always the right thing to do.  I think
you need to look more closely at the underlying types (which I would
think should still be available in expr.c).

  > 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 assignmen t
  > to *p after a read from arr1 in the second strcpy just like happened in the
  > Ada case?
I don't think we can run into problems with this case.

The addresses are not varying in both references so MEM_IN_STRUCT_P
does not apply.

MEM_IN_STRUCT_P only applies if one reference has it and the other
does not *and* the reference with MEM_IN_STRUCT_P is a varying address
and the other is at a constant address.  See sched.c in the gcc2
sources.

jeff







Frst