Hi Paul, yes, please go ahead with the merge. To my astonishment, I had no conflicts with your patch. Mine is addressing copy-in/(out) aka packing/unpacking of derived-type to class-type arguments.
Thanks for the patch. - Andre On Tue, 2 Jul 2024 09:21:26 +0100 Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > 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 -- Andre Vehreschild * Email: vehre ad gmx dot de
