Hi Paul,
thanks for the review. Committed as r241439.
The first nit has gone to the patch for pr78053 as agreed upon.
The second nit:
> + class(r), allocatable :: foo ! Need this declared of copy_R is not
> generated.
has magically disappeared. I assume that it was necessary on an intermediate
stage of the patch only. I now have stripped the above line from the commit and
everything works fine.
Thanks again for the review.
Regards,
Andre
On Sat, 22 Oct 2016 12:41:19 +0200
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> Dear Andre,
>
> For the bulk of the patch, I have no comments. However, for the
> testcase alloc_comp_class_5.f03, please eliminate the commented out
> lines and the TODO, as discussed on #gfortran. Add them to the
> testcase for for PR78053, as we agreed.
>
> In realloc_on_assign_27.f08, you have the following lines:
> + class(t), allocatable :: x
> + class(r), allocatable :: foo ! Need this declared of copy_R is not
> generated.
> + type(r) :: y = r (3, 42)
> +
> + x = y
>
> Surely, if you test for the existence of the vtable and create it if
> necessary for the rhs type in gfc_trans_class_assign, that would
> remove the need for 'foo'?
>
> The patch applies cleanly and regtests OK. Apart from the above nits,
> OK for trunk.
>
> Best regards
>
> Paul
>
> On 22 October 2016 at 12:19, Andre Vehreschild <ve...@gmx.de> wrote:
> > Hi Paul,
> >
> > here is the patch for pr78053 so far. It is based on the one for pr43366.
> > Compilation of the also attached testcase now works. Unfortunately produces
> > the patch a lot of regressions because the length of a char array is not
> > stored any longer in the vtab *and* in the _len component for deferred
> > length char arrays. That still has to be fixed. Given that you have
> > modified a lot on how SELECT TYPE works I fear, that when I change there,
> > too, we get a lot of conflicts. So when you have a version of your patch
> > for pr69834 I am happy to review it and continue work on pr78053
> > afterwards. I think this makes the most sense to avoid duplicate or
> > colliding work.
> >
> > Regards,
> > Andre
> >
--
Andre Vehreschild * Email: vehre ad gmx dot de
