This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Ping: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec
- From: Andre Vehreschild <vehre at gmx dot de>
- To: GCC-Patches-ML <gcc-patches at gcc dot gnu dot org>, GCC-Fortran-ML <fortran at gcc dot gnu dot org>
- Date: Fri, 22 May 2015 12:11:32 +0200
- Subject: Ping: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec
- Authentication-results: sourceware.org; auth=none
- References: <20150330194749 dot 18e21169 at vepi2> <20150401151540 dot 4979eb07 at vepi2> <20150402110330 dot 45ad027b at vepi2> <20150423144511 dot 5e7b12c5 at gmx dot de> <20150429172358 dot 03f42041 at gmx dot de> <20150430161742 dot 1273247f at gmx dot de> <20150519122602 dot 028db8d5 at vepi2>
Hi,
the patch (65548) this one depends on is in trunk now.
Still bootstraps ok and regtests with the issue in
gfortran.dg/alloc_comp_constructor_1.f90 (which is addressed by the patch for
pr58586 already) on x86_64-linux-gnu/f21.
Ok for trunk?
- Andre
On Tue, 19 May 2015 12:26:02 +0200
Andre Vehreschild <vehre@gmx.de> wrote:
> Hi all,
>
> update based on latest 65548 (v5) patch and current trunk. Description and
> issue addressed unchanged (see cite below).
>
> Bootstrapped and regtested on x86_64-linux-gnu/f21.
>
> Any volunteers to review? The initial version dates back to March 30. 2015.
> Not a single comment so far!
>
> - Andre
>
>
>
> On Thu, 30 Apr 2015 16:17:42 +0200
> Andre Vehreschild <vehre@gmx.de> wrote:
>
> > Hi all,
> >
> > and also for this bug, I like to present an updated patch. It was brought to
> > my attention, that the previous patch did not fix statements like:
> >
> > allocate(m, source=[(I, I=1, n)])
> >
> > where n is a variable and
> >
> > type p
> > class(*), allocatable :: m(:,:)
> > end type
> > real mat(2,3)
> > type(P) :: o
> > allocate(o%m, source=mat)
> >
> > The new version of the patch fixes those issue now also and furthermore
> > addresses some issues (most probably not all) where the rank of the
> > source=-variable and the rank of the array to allocate differ. For example,
> > when one is do:
> >
> > real v(:)
> > allocate(v, source= arr(1,2:3))
> >
> > where arr has a rank of 2 and only the source=-expression a rank of one,
> > which is then compatible with v. Nevertheless did this need addressing,
> > when setting up the descriptor of the v and during data copy.
> >
> > Bootstrap ok on x86_64-linux-gnu/f21.
> > Regtests with one regression in gfortran.dg/alloc_comp_constructor_1.f90,
> > which is addressed in the patch for pr58586, whose final version is in
> > preparation.
> >
> > Ok for trunk in combination with 58586 once both are reviewed?
> >
> > Regards,
> > Andre
> >
> >
> > On Wed, 29 Apr 2015 17:23:58 +0200
> > Andre Vehreschild <vehre@gmx.de> wrote:
> >
> > > Hi all,
> > >
> > > this is the fourth version of the patch, adapting to the current state of
> > > trunk. This patch is based on my patch for 65584 version 2 and needs that
> > > patch applied beforehand to apply cleanly. The patch for 65548 is
> > > available from:
> > >
> > > https://gcc.gnu.org/ml/fortran/2015-04/msg00121.html
> > >
> > > Scope:
> > >
> > > Allow allocate of arrays w/o having to give an array-spec as specified in
> > > F2008:C633. An example is:
> > >
> > > integer, dimension(:) :: arr
> > > allocate(arr, source = [1,2,3])
> > >
> > > Solution:
> > >
> > > While resolving an allocate, the objects to allocate are analyzed whether
> > > they carry an array-spec, if not the array-spec of the source=-expression
> > > is transferred. Unfortunately some source=-expressions are not easy to
> > > handle and have to be assigned to a temporary variable first. Only with
> > > the temporary variable the gfc_trans_allocate() is then able to compute
> > > the array descriptor correctly and allocate with correct array bounds.
> > >
> > > Side notes:
> > >
> > > This patch creates a regression in alloc_comp_constructor_1.f90 where two
> > > free()'s are gone missing. This will be fixed by the patch for pr58586 and
> > > therefore not repeated here.
> > >
> > > Bootstraps and regtests ok on x86_64-linux-gnu/f21.
> > >
> > > Ok for trunk?
> > >
> > > Regards,
> > > Andre
> > >
> >
> >
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de