This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Ping, Patch, fortran, PR44672, v3] [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>, Antony Lewis <antony at cosmologist dot info>, Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Date: Thu, 23 Apr 2015 14:45:11 +0200
- Subject: Re: [Ping, Patch, fortran, PR44672, v3] [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>
Ping !
On Thu, 2 Apr 2015 11:03:30 +0200
Andre Vehreschild <vehre@gmx.de> wrote:
> Hi all,
>
> during debugging of a larger fortran source I figured that my previous patch
> on 44672 had still some issues, when it comes to adding a gfc_code into the
> chain of codes and with a symbol. Adding a new gfc_code object before the
> current one is now solved be creating a new gfc_code object, copying the
> current one to the new one, initialize the old one to the new data and
> setting its next pointer to the current one. Because in the
> gfc_code.ext.alloc a flag is introduced, that is only set by the C-code
> adding a new gfc_code object, that flag can be used to prevent doing this
> process endlessly. I also learned, that one has to commit newly created
> symbols or one may get a very strange error in an assert in
> gfc_enforce_clean_symbol_state (). After adding the gfc_commit_symbol ()
> everything was fine.
>
> Bootstraps and regtests ok on x86_64-linux-gnu/F20.
>
> Ok for 5.2 trunk?
>
> Regards,
> Andre
>
> On Wed, 1 Apr 2015 15:15:40 +0200
> Andre Vehreschild <vehre@gmx.de> wrote:
>
> > Hi all,
> >
> > during debugging another fortran code, I figured that some cases were not
> > yet met. Especially the case where a class array is in the source= or mold=
> > expression. This new version of the patch fixes the issue now.
> >
> > Bootstraps and regtests ok on x86_64-linux-gnu/F20.
> >
> > Ok for 5.2 trunk?
> >
> > Regards,
> > Andre
> >
> > On Mon, 30 Mar 2015 19:47:49 +0200
> > Andre Vehreschild <vehre@gmx.de> wrote:
> >
> > > Dear all,
> > >
> > > please find attach a patch fixing pr44672:
> > >
> > > integer, dimension(:) :: arr
> > > allocate(arr, source = [1,2,3])
> > >
> > > as for F2008:C633 now is no longer flagged, beside when you insist on
> > > -std=f2003 or lower. Furthermore does the patch implement the F2008
> > > feature of obsoleting the explicit array specification on the arrays to
> > > allocate, when an array valued source=/mold= expression is given.
> > >
> > > Bootstrap and regtests ok on x86_64-linux-gnu/F20.
> > >
> > > This batched is based on a trunk having my latest for pr60322 patched in
> > > (else deltas may occur).
> > >
> > > Ok for 5.2 trunk?
> > >
> > > Regards,
> > > Andre
> >
> >
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de