Re: [Ping, Patch 2/2, v3, Fortran, pr60322 a.o.] [OOP] Incorrect bounds on polymorphic dummy array

[Andre Vehreschild <vehre at gmx dot de>]

Ping!

On Fri, 6 Mar 2015 13:38:21 +0100
Andre Vehreschild <vehre@gmx.de> wrote:

> 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