Hi everyone,

please find attached the latest version of the patch with the comments from
Dominique via IRC worked in. Those were mostly about clarifying comments and
style. Nevertheless, thanks for your help Dominique.

Still basing on the first part of the patch at:

https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html

Bootstraps and regtests fine on x86_64-linux-gnu/F20.

Reviews welcome. 

Regards,
	Andre


On Wed, 4 Mar 2015 20:30:15 +0100
Andre Vehreschild <vehre@gmx.de> wrote:

> Dear all,
> 
> during his initial tests Dominique pointed out, that my patch did not fix all
> issues in the comments of pr60322. This new version of the patch fixes this
> issue now. The trick is to use a temporary array in the variable association
> of select type statements. The old code referenced the incoming array
> directly. This array may have an arbitrary base (i.e. lbound != 1) making
> indexing very difficult. Creating a temporary array descriptor for the
> associated variable allows for having the array base set to one (i.e., lbound
> == 1) making indexing fairly simple and adhere to the Fortran rules.
> 
> The patch boostraps and regtests cleanly on x86_64-linux-gnu/F20. 
> 
> Note, you need to apply part 1 of this patch first. Part 1 can be found at:
> 
> https://gcc.gnu.org/ml/fortran/2015-02/msg00105.html
> 
> Regards,
> 	Andre
> 
> On Thu, 26 Feb 2015 18:17:21 +0100
> Andre Vehreschild <vehre@gmx.de> wrote:
> 
> > Hi all,
> > 
> > here is the second part of the patch for pr60322. This patch also addresses
> > the issue reported in pr64692, ... (more to come).
> > 
> > The patch fixes the incorrect bounds of polymorphic arrays used to call
> > functions and subroutines by using the same mechanism as regular arrays. In
> > fact most of the code for treating regular arrays is reused by simply
> > inserting the class array's symbol_attributes and gfc_array_specs into the
> > same routines, i.e., doing the switching whether a symbol is a class array
> > or a regular array and assigning the CLASS_DATA(sym).attr or sym.attr to the
> > symbol_attribute temporary variable introduced by the first part (same for
> > gfc_array_spec). The temporary array descriptor is then stored in the tree
> > and extracted were it is needed.
> > 
> > This patch furthermore addresses an issue with elemental functions, where
> > the elemental function was not applied to class array members. By
> > introducing the temporary array this merely fixed itself.
> > 
> > During fixing elemental function application, an issue about using the
> > polymorphic initializer popped up. The existing code would declare a
> > variable of the base type (not a reference or pointer to it), assign the
> > _vptr's _def_init to it and use the _vptr's _copy to copy the initializer
> > into the object to initialize. This had to be patched to use a pointer for
> > the variable and the correct addressing to be able to make use of the
> > polymorphic init.
> > 
> > Furthermore is the array offset in certain cases set to be -1. This helped
> > to get the addressing correct for subarrays of (unlimited polymorphic)
> > objects, where the array offset is used in a "select type" or other kind of
> > association and the with the offset set incorrectly wrong elements from the
> > array were selected.
> > 
> > I had to fix two testcases, too:
> > - finalize_15: We agreed (including checking with other compilers) that the
> >   value of an intent(out) variable should be that of its initializer and not
> >   that of its finalizer.
> > - finalize_10: By using the temporary arrays the scan-tree-count expressions
> >   had to be adapted, too.
> > 
> > Thank you's go to: Tobias, Dominique and Paul for their support during
> > figuring what it going wrong and thorough testing and to Antony for
> > reporting the issue.
> > 
> > Bootstraps and regtests ok on x86_64-linux-gnu/F20.
> > 
> > Regards,
> > 	Andre
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de