Ping! On Fri, 6 Mar 2015 13:38:21 +0100 Andre Vehreschild <ve...@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 <ve...@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 <ve...@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
