Hi Paul,

thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c
and backported to gcc-13 as d9b3269bdccac2db9200303494c4e82f2aeb7bbc
Thanks for the fast review.

Regards,
        Andre

On Fri, 29 Sep 2023 13:38:57 +0100
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:

> Hi Andre,
>
> Yes indeed - it's fine for trunk and, I would suggest, 13-branch.
>
> Cheers
>
> Paul
>
> On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild <ve...@gmx.de> wrote:
> >
> > Hi Paul,
> >
> > thanks for the quick review. I've added a testcase with a module and a
> > finalizer in the derived type. This also is no problem.
> >
> > Regtests ok on x86_64_linux_gnu/f37. Ok for trunk?
> >
> > Regards,
> >         Andre
> >
> > On Thu, 28 Sep 2023 19:21:12 +0100
> > Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> >
> > > Hi Andre,
> > >
> > > The patch looks fine to me. Since you mention it in the comment, is it
> > > worth declaring the derived type 'foo' in a module and giving it a
> > > final routine?
> > >
> > > Thanks for the patch.
> > >
> > > Paul
> > >
> > > On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran
> > > <fort...@gcc.gnu.org> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > attached patch fixes a crash in coarray programs when an allocatable
> > > > derived typed coarray was freed explicitly. The generated cleanup code
> > > > did not take into account, that the coarray may have been deallocated
> > > > already. The patch fixes this by moving the statements accessing
> > > > components inside the derived type into the block guard by its
> > > > allocated check.
> > > >
> > > > Regtested ok on f37/x86_64. Ok for master?
> > > >
> > > > Regards,
> > > >         Andre
> > > > --
> > > > Andre Vehreschild * Email: vehre ad gmx dot de
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de


--
Andre Vehreschild * Email: vehre ad gmx dot de

Reply via email to