Re: Your June 7 change to expand_expr

[Jim Wilson <wilson at cygnus dot com>]

MEM_IN_STRUCT_P doesn't have a well defined meaning on its own.  It is well
defined only when considered in conjunction with whether the MEM has a
varying address.  This is because MEM_IN_STRUCT_P is used for only one
thing, an aliasing rule, and this aliasing rule looks at both both values.

As such, there does exist a safe value for MEM_IN_STRUCT_P, it is the value
that will cause the aliasing rule to detect an alias.  This would be something
like
	MEM_IN_STRUCT_P (x) = ! varies (XEXP (x, 0));
This is save, assuming that all later passes preserve the two values.
It so happens that most aliasing failures can be fixed by setting
MEM_IN_STRUCT_P to one, but that is only because most aliasing failures
tend to occur for stack based addresses which are non-varying, and hence
the safe value for them is one.

I think the real problem here is that Kenner is redefining what a 
REFERENCE_TYPE is.  The C++ front end has been using this for a long time
to implement the C++ references.  References are similar to pointers, but
not exactly the same.  The Ada front end has not been using REFERENCE_TYPE.

But now Kenner has run into a problem, and needed something that was like
a pointer but different, and since we already had REFERENCE_TYPE, he started
using them.  Unfortunately, he is using them in a different way than the
C++ front end is using them.  In C++, a REFERENCE_TYPE points at an object.
In Ada, a REFERENCE_TYPE points into an object.  These are not the same thing,
and this has apparently led to the MEM_IN_STRUCT_P problem.  This is just
an educated guess at this time though.

I think it is wrong to set MEM_IN_STRUCT_P for a REFERENCE_TYPE.  I don't
believe that this problem justifies defining a new bit to indicate whether
MEM_IN_STRUCT_P is valid.  I think egcs should remove Kenner's patch
until this problem is worked out.  We could probably solve this problem by
setting MEM_IN_STRUCT_P for a REFERENCE_TYPE if the language is Ada, but
I don't think that is an elegant enough solution.

What I would like to see is a better explanation of how the Ada front end
is trying to use REFERENCE_TYPEs, and a testcase for the Ada front end problem
that prompted Kenner to start setting MEM_IN_STRUCT_P for REFERENCE_TYPEs.
This may mean access to more recent Ada front end sources, since the ones I
happen to have (3.10p) do not use REFERENCE_TYPEs.  If it is necessary to make
changes to REFERENCE_TYPEs, then it should be discussed in some open forum
rather than privately decided by the Ada front end folks.

There was a comment about the testcase 980506-2.c demonstrating how cse changes
MEM_IN_STRUCT_P in an unsafe manner.  This isn't quite correct, because cse
doesn't change MEM_IN_STRUCT_P.  The problem there is that cse modifies the
mem address, changing it from a varying one to a nonvarying one (or vice
versa), hence hence causing the aliasing rule to give the wrong result.
This problem can be fixed by making the varying property a bit in the MEM
instead of a bit determined from the current RTL.  The aliasing rule is
correct only  if the original address is varying, not if the current address
is varying, and hence it would fix this testcase.  If we do decide to add
a second bit, I think this is the bit that we should be adding, as this
would fix the existing known bugs with the MEM_IN_STRUCT_P aliasing code.
It is possible that this is the bug that Kenner ran into with the Ada
front end, but I can't tell without more info.

Jim