This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Ping: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec


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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]