This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Fortran, Patch, PR{43366, 57117, 61337, 61376}, v1] Assign to polymorphic objects.
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Andre Vehreschild <vehre at gmx dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Cc: Dominique Dhumieres <dominiq at lps dot ens dot fr>
- Date: Sat, 22 Oct 2016 12:41:19 +0200
- Subject: Re: [Fortran, Patch, PR{43366, 57117, 61337, 61376}, v1] Assign to polymorphic objects.
- Authentication-results: sourceware.org; auth=none
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
>