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

[Andre Vehreschild]

Hi all,

attached is an enhanced version of the patch, which now catches all of the
testcases in the comments of pr61337. Thanks for reporting that I missed them,
Dominique.

For a detailed description see below. PR61337 needed just some more pre-code
joining and correct handling of class-typed array constructors.

Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk?

Regards,
	Andre

On Thu, 13 Oct 2016 14:42:00 +0200
Andre Vehreschild <vehre@gmx.de> wrote:

> Hi all,
> 
> attached patch fixes the PRs (as to my knowledge):
> 
> PR43366 - [OOP][F08] Intrinsic assign to polymorphic variable
> PR57117 - [OOP] ICE for sourced allocation of a polymorphic entity using
> 	  TRANSPOSE
> PR61337 - Wrong indexing and runtime crash with unlimited polymorphic array.
> PR61378 - Error using private statement in polymorphic derived type
> 
> The latter two are more or less fixed by accident or have been fixed by
> previous patches, but have not been identified as such. Anyway, they are fixed
> now and will be closed once the patch hits trunk.
> 
> As for PR43366: I did not indent to fix this one, but when going for PR57117 I
> once again stumbled over the deficiencies of gfc_trans_assigment's handling of
> class objects. Therefore I figured what would be needed to complete PR43366
> and this is it now. 
> 
> As for PR57117: The issue was that ALLOCATE () used gfc_copy_class_to_class ()
> when a class object was allocated. The function gfc_copy_class_to_class ()
> does not use the scalarizer correctly. I.e., a transpose of the source=
> expression would not be respected. I therefore decided to remove all this
> special casing for class objects in ALLOCATE () and let gfc_trans_assignment
> do the trick. This way ensuring, that any improvements of the scalarizer will
> benefit class objects, too. Unfortunately did this mean to add more logic to
> gfc_trans_assignment. While doing so, I learned that existing wrappers for
> class assignments were obsoleted by the work I did, so I removed them.
> 
> I tried to get rid of the malicious copy_class_to_class, too, but at the
> moment it is still used at one location where components of derived types are
> assigned. I was not bold enough to replace this occurrence with
> trans_assignment yet.
> 
> This patch shall make our lives easier, because now there is one routine to
> assign all sorts of objects and no special casing for class objects is needed
> anymore. I expect that some other parts of gfortran's code base may benefit
> from the changes and have their complexity reduced.
> 
> Bootstrapped and regtested ok on x86_64-linux/F23. Ok for trunk?
> 
> Regards,
> 	Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr43366_v2.clog
Type: application/octet-stream
Size: 2534 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20161019/a4a70dfd/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr43366_v2.patch
Type: text/x-patch
Size: 57546 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20161019/a4a70dfd/attachment.bin>