Re: [Fortran, Patch, PR{43366, 57117, 61337, 61376}, v1] Assign to polymorphic objects.

[Andre Vehreschild <vehre@gmx.de>]

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.thomas@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 <vehre@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