Hi Andre,
Thank you for the review.
> ...snip...
>
> I am confused here, because you are assigning to rhs. When that is
> correct, why
> is there no else assigning zero to the rhs->_len when arg1 is not
> unlimited?
'rhs_class_expr' is highly confusing and came from the original use of this
part of the code. With this function call, it is actually the lhs! I will
think of some less confusing name and extend the comment above its
extraction from the ss chain.
d._vptr = b._vptr;
d._len = b._len; // Here is the assignment that you pointed out.
D.5162 = d._vptr != 0B ? d._vptr->_size : 0;
D.5163 = D.5162;
D.5164 = d._len;
D.5165 = D.5164 > 0 ? D.5163 * D.5164 : D.5163;
typedef character(kind=1) [10][1:D.5165];
ctmp.123 = d; // This looks a bit silly but it is effective for
more complicated objects - eg. class components.
ctmp.123._data = atmp.122;
ctmp.123._data.dtype = d._data.dtype;
ctmp.123._data.dtype.rank = 1;
ctmp.123._data.dim[0].stride = 1;
ctmp.123._data.dim[0].lbound = 0;
ctmp.123._data.dim[0].ubound = 9;
ctmp.123._data.span = D.5165;
D.5174 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
(D.5165 * 10), 1>);
D.5175 = D.5174;
ctmp.123._data.data = D.5175;
ctmp.123._data.offset = 0;
_gfortran_reshape (&ctmp.123._data, D.5152, D.5161, 0B, 0B);
>
> @@ -1176,6 +1176,21 @@ gfc_conv_class_to_class (gfc_se *parmse, gfc_expr
> *e,
> gfc_typespec class_ts, stmtblock_t block;
> bool full_array = false;
>
> + /* Class transformational function results are the data field of a class
> + temporary and so the class expression canbe obtained directly. */
>
> s/canbe/can be/
>
> Indeed!
>
> Besides those small knits the patch looks fine to me. I am wondering
> though,
> why gfortran is still using a non-class aware pack? To "move" the content
> of a
> class object the _copy function of the vtype is to be used, right? In my
> current PR I try to implement a class aware internal pack (and unpack) to
> correctly apply the element sequence as of F2018 15.5.2.11. But I am
> struggling when the rank changes. I found the idea how to do this
> correctly in
> your code, thanks.
>
It crossed my mind that class aware transformationals would have been the
path of least resistance *after* I had fought my way through the ss chains.
The full list of affected transformational intrinsics that operate on any
type is found in the second testcase. If you tackle pack first, I would be
happy to do the rest and to assign this patch to the dustbin of history. It
should be rather straightforward to provide an interface to the existing
library functions that produces significantly less inline code than my
implementation.
I will commit the patch, though, and will revert as and when class-aware
library functions are in place.
Thanks again
Paul
