From: Andre Vehreschild <vehre@gmx.de>
To: GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
GCC-Fortran-ML <fortran@gcc.gnu.org>
Subject: Ping: [Patch, fortran, PR44672, v6] [F08] ALLOCATE with SOURCE and no array-spec
Date: Fri, 22 May 2015 10:24:00 -0000 [thread overview]
Message-ID: <20150522121132.11a2f6d4@vepi2> (raw)
In-Reply-To: <20150519122602.028db8d5@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
next prev parent reply other threads:[~2015-05-22 10:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 17:48 [Patch, fortran, PR44672, v1] " Andre Vehreschild
2015-04-01 13:15 ` [Patch, fortran, PR44672, v2] " Andre Vehreschild
2015-04-02 9:03 ` [Patch, fortran, PR44672, v3] " Andre Vehreschild
2015-04-23 12:45 ` [Ping, Patch, " Andre Vehreschild
2015-04-29 15:29 ` [Patch, fortran, PR44672, v4] " Andre Vehreschild
2015-04-30 14:31 ` [Patch, fortran, PR44672, v5] " Andre Vehreschild
2015-05-19 10:29 ` [Patch, fortran, PR44672, v6] " Andre Vehreschild
2015-05-22 10:24 ` Andre Vehreschild [this message]
2015-05-25 19:35 ` Mikael Morin
2015-05-28 15:48 ` Andre Vehreschild
2015-05-28 18:42 ` Mikael Morin
2015-05-29 12:41 ` Andre Vehreschild
2015-05-30 4:23 ` Thomas Koenig
2015-06-02 16:52 ` Mikael Morin
2015-06-03 15:25 ` Andre Vehreschild
2015-06-05 12:04 ` [Patch, fortran, PR44672, v9] " Andre Vehreschild
2015-06-09 5:36 ` Damian Rouson
2015-06-10 8:59 ` [Patch, fortran, PR44672, v10] " Andre Vehreschild
2015-06-11 22:05 ` Thomas Koenig
2015-06-12 8:00 ` Andre Vehreschild
2015-06-15 10:43 ` Andre Vehreschild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150522121132.11a2f6d4@vepi2 \
--to=vehre@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).