[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #21 from martin --- *** Bug 88899 has been marked as a duplicate of this bug. ***
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 Harald Anlauf changed: What|Removed |Added Target Milestone|--- |15.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Harald Anlauf --- Fixed in trunk, and backported to 16- and 15-release branches. Closing. Thanks for the report!
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059
--- Comment #19 from GCC Commits ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:2acc6fd276b48579f712d1016519c0b2382a6aa6
commit r15-11177-g2acc6fd276b48579f712d1016519c0b2382a6aa6
Author: Harald Anlauf
Date: Thu May 7 22:34:52 2026 +0200
Fortran: fix automatic deallocation with derived type IO
[PR111952,PR125059]
The implementation of derived type IO wrongly forced allocatable instances
of the DT as static, which prevented automatic deallocation of local
variables. The motivation was an attempt to prevent optimizations leading
to certain testcase failures. Howver, the underlying reason of the problem
was a wrong fnspec of _gfortran_transfer_derived that declared the IO
variable as being only read ('r'). Declare the corresponding parameter as
being written ('w').
PR fortran/111952
PR fortran/125059
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_finish_var_decl): Remove bogus code forcing
a DT variable with DTIO as static.
* trans-io.cc (gfc_build_io_library_fndecls): Fix fnspec attribute.
gcc/testsuite/ChangeLog:
* gfortran.dg/dtio_37.f90: New test.
(cherry picked from commit 1904b9207203bbe45d6ce6a472d6a0c7e1bbd873)
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059
--- Comment #18 from GCC Commits ---
The releases/gcc-16 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:ef03d3cfb45e0d75c137223c805ad75a3b7e319d
commit r16-8905-gef03d3cfb45e0d75c137223c805ad75a3b7e319d
Author: Harald Anlauf
Date: Thu May 7 22:34:52 2026 +0200
Fortran: fix automatic deallocation with derived type IO
[PR111952,PR125059]
The implementation of derived type IO wrongly forced allocatable instances
of the DT as static, which prevented automatic deallocation of local
variables. The motivation was an attempt to prevent optimizations leading
to certain testcase failures. Howver, the underlying reason of the problem
was a wrong fnspec of _gfortran_transfer_derived that declared the IO
variable as being only read ('r'). Declare the corresponding parameter as
being written ('w').
PR fortran/111952
PR fortran/125059
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_finish_var_decl): Remove bogus code forcing
a DT variable with DTIO as static.
* trans-io.cc (gfc_build_io_library_fndecls): Fix fnspec attribute.
gcc/testsuite/ChangeLog:
* gfortran.dg/dtio_37.f90: New test.
(cherry picked from commit 1904b9207203bbe45d6ce6a472d6a0c7e1bbd873)
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #17 from anlauf at gcc dot gnu.org --- *** Bug 88768 has been marked as a duplicate of this bug. ***
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #14) > (In reply to martin from comment #13) > > I do not understand much of the thread and IR, but reading STATIC in > > conjunction with DTIO got me interested: Could this be possibly closely > > related (or rather same root cause) to bug 88899 and bug 88768? > > The 88899 defitely looks like the same bug. The 88768 likely. After the > patch goes in can you test it again? PR88768 is fixed here after the patch. I'll mark it as a duplicate. PR88899 is fixed here with up to 8 threads. If you can confirm that it works for you, would you please mark it as a dup, too?
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059
--- Comment #15 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:1904b9207203bbe45d6ce6a472d6a0c7e1bbd873
commit r17-410-g1904b9207203bbe45d6ce6a472d6a0c7e1bbd873
Author: Harald Anlauf
Date: Thu May 7 22:34:52 2026 +0200
Fortran: fix automatic deallocation with derived type IO
[PR111952,PR125059]
The implementation of derived type IO wrongly forced allocatable instances
of the DT as static, which prevented automatic deallocation of local
variables. The motivation was an attempt to prevent optimizations leading
to certain testcase failures. Howver, the underlying reason of the problem
was a wrong fnspec of _gfortran_transfer_derived that declared the IO
variable as being only read ('r'). Declare the corresponding parameter as
being written ('w').
PR fortran/111952
PR fortran/125059
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_finish_var_decl): Remove bogus code forcing
a DT variable with DTIO as static.
* trans-io.cc (gfc_build_io_library_fndecls): Fix fnspec attribute.
gcc/testsuite/ChangeLog:
* gfortran.dg/dtio_37.f90: New test.
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #14 from Jerry DeLisle --- (In reply to martin from comment #13) > I do not understand much of the thread and IR, but reading STATIC in > conjunction with DTIO got me interested: Could this be possibly closely > related (or rather same root cause) to bug 88899 and bug 88768? The 88899 defitely looks like the same bug. The 88768 likely. After the patch goes in can you test it again?
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 martin changed: What|Removed |Added CC||mscfd at gmx dot net --- Comment #13 from martin --- I do not understand much of the thread and IR, but reading STATIC in conjunction with DTIO got me interested: Could this be possibly closely related (or rather same root cause) to bug 88899 and bug 88768?
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||federico.perini at gmail dot com --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 111952 has been marked as a duplicate of this bug. ***
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2026-May/063874.html
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> (In reply to Jerry DeLisle from comment #8)
> > This seems to fix this:
> >
> > diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
> > index 4b3f75ced71..ae451da04e8 100644
> > --- a/gcc/fortran/trans-decl.cc
> > +++ b/gcc/fortran/trans-decl.cc
> > @@ -764,7 +764,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
> > && sym->ts.u.derived->attr.has_dtio_procs)
> > || (sym->ts.type == BT_CLASS
> > && CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs)))
> > -TREE_STATIC (decl) = 1;
> > +TREE_THIS_VOLATILE (decl) = 1;
> >
> >/* Treat asynchronous variables the same as volatile, for now. */
> >if (sym->attr.volatile_ || sym->attr.asynchronous)
> Maybe we are barking up the wrong tree, and the issue is actually
> with the read!
>
> Should it set the variable udt1 as modified?
Actually commenting the code fragment above and applying this patch works!
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index a18b2bca6aa..046fb57bcd0 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -416,7 +416,7 @@ gfc_build_io_library_fndecls (void)
integer_type_node, gfc_charlen_type_node);
iocall[IOCALL_X_DERIVED] = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("transfer_derived")), ". w r ",
+ get_identifier (PREFIX("transfer_derived")), ". w w ",
void_type_node, 2, dt_parm_type, pvoid_type_node);
/* Library entry points */
Can this be correct?
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #8) > This seems to fix this: > > diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc > index 4b3f75ced71..ae451da04e8 100644 > --- a/gcc/fortran/trans-decl.cc > +++ b/gcc/fortran/trans-decl.cc > @@ -764,7 +764,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) > && sym->ts.u.derived->attr.has_dtio_procs) > || (sym->ts.type == BT_CLASS > && CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs))) > -TREE_STATIC (decl) = 1; > +TREE_THIS_VOLATILE (decl) = 1; > >/* Treat asynchronous variables the same as volatile, for now. */ >if (sym->attr.volatile_ || sym->attr.asynchronous) I thought of the same modification and also saw: > Running target unix > FAIL: gfortran.dg/dtio_4.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions execution test > FAIL: gfortran.dg/dtio_4.f90 -O3 -g execution test Comparing the optimized dump shows the following types of differences after the above: [local count: 30384459]: - _8 = MEM[(integer(kind=4)[15] *)&udt1][14]; _9 = result_array[14]; - if (_8 != _9) + if (_9 != 99) goto ; [5.50%] else goto ; [94.50%] For some reason the optimizer thinks that it can optimize if (any(udt1%myarray.ne.result_array)) STOP 2 although the read sets udt1%myarray to the same as result_array (confirmed by an explicit print). Even setting volatile :: udt1 has no effect on the above optimized code. Note that the 99 comes from initialization udt1%myarray = 99 and it should get overwritten by the read. Maybe we are barking up the wrong tree, and the issue is actually with the read! Should it set the variable udt1 as modified?
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #8 from Jerry DeLisle --- This seems to fix this: diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc index 4b3f75ced71..ae451da04e8 100644 --- a/gcc/fortran/trans-decl.cc +++ b/gcc/fortran/trans-decl.cc @@ -764,7 +764,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) && sym->ts.u.derived->attr.has_dtio_procs) || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs))) -TREE_STATIC (decl) = 1; +TREE_THIS_VOLATILE (decl) = 1; /* Treat asynchronous variables the same as volatile, for now. */ if (sym->attr.volatile_ || sym->attr.asynchronous) Almost works: === gfortran tests === Running target unix FAIL: gfortran.dg/dtio_4.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/dtio_4.f90 -O3 -g execution test === gfortran Summary === # of expected passes75466 # of unexpected failures2 # of expected failures 345 # of unsupported tests 85 Not quite right.
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #7 from Jerry DeLisle --- (In reply to anlauf from comment #6) > This code was added in r7-2882-ge73d3ca6d1caf9 . This is a long time ago. Could we possibly add a deallocation call in trans-io.cc? or possibly at run time library itself.
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #6 from anlauf at gcc dot gnu.org --- This code was added in r7-2882-ge73d3ca6d1caf9 .
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- We are hitting the following code in gfc_finish_var_decl: /* If derived-type variables with DTIO procedures are not made static some bits of code referencing them get optimized away. TODO Understand why this is so and fix it. */ if (!sym->attr.use_assoc && ((sym->ts.type == BT_DERIVED && sym->ts.u.derived->attr.has_dtio_procs) || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs))) TREE_STATIC (decl) = 1; @Paul: do you remember details of this code?
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
I noted that the "print*,a(1)" can be commented and the bug persists.
Adding an explicit deallocate (a) in subroutine f hides the issue.
Interestingly, the issue depends on the line
generic::write(formatted)=>w
Comparing the tree dumps with this line either active or commented changes
the local allocatable array between static and automatic!
static struct array01_t a = {.data=0B};
vs.
struct array01_t a;
where only the latter does automatic deallocation on exit from f.
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2026-04-29 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Vladimir Terzi from comment #2) > (In reply to anlauf from comment #1) > > Very similar to pr111952. Possibly a duplicate. > > You are right. My bug report is a duplicate but for another version. I > didn't know about the original bug report since the search that uses only > titles rarely helps. By chance I just remembered having seen the other PR.
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 --- Comment #2 from Vladimir Terzi --- (In reply to anlauf from comment #1) > Very similar to pr111952. Possibly a duplicate. You are right. My bug report is a duplicate but for another version. I didn't know about the original bug report since the search that uses only titles rarely helps.
[Bug fortran/125059] Missing deallocation of derived type arrays with `write(formatted)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125059 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111952 --- Comment #1 from anlauf at gcc dot gnu.org --- Very similar to pr111952. Possibly a duplicate.
