http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #80 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-08-01
16:22:52 UTC ---
(In reply to comment #79)
> > this%y = this%find_y() ! FAILS
> >
> > the lhs is a target, and the rhs is NOT a target, so that the middle-end
> > types
> > are different. :-(
>
> But how can this be a valid fortran program? You assign something
> that is not aliased to something that suddenly makes it aliased?
> If that's valid then you can make the middle-end happy by wrapping
> the RHS inside a VIEW_CONVERT_EXPR with the LHS type.
I have not closely looked at the dump, however,
this%y = this%find_y()
means that one assigns component-wise the values from the RHS to the LHS; if
there are pointer components, the pointer address is assigned; if there are
allocatable components, those are - if needed - first (re)allocated and then
(element-wise) assigned.
Thus, one only assigns the values and no pointers - and, hence, the RHS can be
a nontarget while the LHS can be a target.
In this example, "this%y" is a derived type with an allocatable-array
component. I think the current algorithm is something like:
*dst = *src;
if (src->data)
{
(re)allocate dst->data
memcpy (dst->data, src->data);
}
Thus, one first transfers the pointer address [besides the array bounds], but
if "data" is not NULL, the data is copied. Thus, it should be safe - but an
ARRAY_RANGE_REF could be nicer than a memcpy, and the VIEW_CONVERT_EXPR could
be inserted.
