------- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-07-09 15:06 -------
Subject: Re: problem with structure and calling a function
paulthomas2 at wanadoo dot fr wrote:
> I think that your pointer example is another bug. Whether it should be
> considered to be in gfc_trans_pointer_assignment itself or in
> gfc_conv_expr_descriptor should be thought through. It seems to me that
> fixing
> the latter would open the same can of worms that we have discussed for
> gfc_trans_assignment. This time, I am not sure that there is solution, except
> for the third. Using temporaries will not work, since the temporary would
> have
> to be updated each time the target value changed. Modifying the stride will
> not
> work for the same reasons as for a non-pointer assignment. If size is used,
> can
> we be sure that the rest of the compiler will pick it up?
I was a little surprised that the code I gave is allowed at all, given that
this opens all kinds of cans of worms. Say,
type a
real*8 :: x
integer*1 :: i
end type
type(a), target :: v(50)
real, pointer :: p(:)
p => v(:)%x
Lovely, now we have to skip something which probably has a different size and
probably alignment.
I don't agree that gfc_trans_pointer_assignment can be made out to be the
culprit -- pointer assignment to an array-valued pointer means assignment of
an array descriptor, so we have to be able to generate correct array
descriptors even in these pathological cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
