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