Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
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 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
> 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
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e0fc8ebc46b..8e94a9a469f 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9320,6 +9320,12 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl, tree dest,
gfc_add_expr_to_block (&fnblock, tmp);
}
+ /* Still having a descriptor array of rank == 0 here, indicates an
+ allocatable coarrays. Dereference it correctly. */
+ if (GFC_DESCRIPTOR_TYPE_P (decl_type))
+{
+ decl = build_fold_indirect_ref (gfc_conv_array_data (decl));
+}
/* Otherwise, act on the components or recursively call self to
act on a chain of components. */
for (c = der_type->components; c; c = c->next)
@@ -11507,7 +11513,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
{
int rank;
rank = sym->as ? sym->as->rank : 0;
- tmp = gfc_deallocate_alloc_comp (sym->ts.u.derived, descriptor, rank);
+ tmp = gfc_deallocate_alloc_comp (sym->ts.u.derived, descriptor, rank,
+ (sym->attr.codimension
+ && flag_coarray == GFC_FCOARRAY_LIB)
+ ? GFC_STRUCTURE_CAF_MODE_IN_COARRAY
+ : 0);
gfc_add_expr_to_block (&cleanup, tmp);
}
@@ -11521,9 +11531,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
NULL_TREE, NULL_TREE, true, e,
sym->attr.codimension
? GFC_CAF_COARRAY_DEREGISTER
- : GFC_CAF_COARRAY_NOCOARRAY);
+ : GFC_CAF_COARRAY_NOCOARRAY,
+ NULL_TREE, gfc_finish_block (&cleanup));
if (e)
gfc_free_expr (e);
+ gfc_init_block (&cleanup);
gfc_add_expr_to_block (&cleanup, tmp);
}
diff --git a/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90
new file mode 100644
index 000..e8a74db2c18
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_6.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+
+program alloc_comp_6
+
+ implicit none
+
+ type :: foo
+real :: x
+integer, allocatable :: y(:)
+ end type
+
+ call check()
+
+contains
+
+ subroutine check()
+block
+ type(foo), allocatable :: example[:] ! needs to be a coarray
+
+ allocate(example[*])
+ allocate(example%y(10))
+ example%x = 3.4
+ example%y = 4
+
+ deallocate(example)
+end block ! example%y shall not be accessed here by the finalizer,
+ ! because example is already deallocated
+ end subroutine check
+end program alloc_comp_6
diff --git a/gcc/testsuite/gfortran.dg/coarray/alloc_comp_7.f90 b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_7.f90
new file mode 100644
index 000..5ebd31f3df7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/alloc_comp_7.f90
@@ -0,0 +1,49 @@
+! { dg-do run }
+
+module alloc_comp_module_7
+
+ public :: check
+
+ type :: foo
+real :: x
+integer, allocatable :: y(:)
+ contains
+final :: foo_final
+ end type
+
+contains
+
+ subroutine foo_final(f)
+type(foo), intent(inout) :: f
+
+if (allocated(f%y)) then
+ f%y = -1
+end if
+ end subroutine foo_final
+
+ subroutine check()
+block
+ type(foo), allocatable :: example[:] ! needs to be a coarray
+
+ allocate(example[*])
+ allocate(example%y(10))
+ example%x = 3.4
+ example%y = 4
+
+ deallocate(example%y)
+ deallocate(example)
+end block ! example%y shall not be accessed here by the finalizer,
+ ! because example is already deallocated
+ end subroutine check
+end module alloc_comp_module_7
+
+program alloc_comp_7
+
+ use alloc_comp_module_7, only: check
+
+ implicit none
+
+ call check()
+
+end program alloc_comp_7
+
Fortran: Free alloc. comp. in allocated coarrays only.
When freeing allocatable components of an allocatable coarray, add
a
Re: Test with an lto-build of libgfortran.
On 28/09/2023 20:59, Toon Moene wrote:
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a
year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO in lib*.a libraries, at least in some packagings (if the static
libraries are in gcc specific subdirectories rather than say
/usr/lib{,64}
or similar and if the packaging of gcc updates both the compiler and
corresponding static libraries in a lock-step. Because in that case LTO
in there will be always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.
This might be an argument to make it a configure option, e.g.
--enable-lto-runtime.
This sort of thing should definitely Just Work for cross compilers and
embedded platforms where the libraries are bundled with the compiler.
Andrew
Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
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 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 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 > > 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
Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.
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 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 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 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 > > > 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
