The master branch has been updated by Jerry DeLisle <[email protected]>:
https://gcc.gnu.org/g:9579e3eb64ec89c4c0781bb0a59409f15c997213
commit r17-1786-g9579e3eb64ec89c4c0781bb0a59409f15c997213
Author: Jerry DeLisle <[email protected]>
Date: Fri Jun 19 14:54:00 2026 -0700
The fix for the leak in pdt_82.f03
On 6/23/26 12:25 PM, Jerry D wrote:
On 6/23/26 3:00 AM, Paul Richard Thomas wrote:
Hello Jerry and Harald,
The patch does what it says on the box and regression tests correctly.
Except for one very important detail. Its fixing the leak in pdt_82 not pdt_86.
One of the last things I do before getting ready to push a fix is check to see
if the original problem is fixed. So, I dutifully was checking to make sure the
pdt_86 leak was fixed. It wasn't. That sent me into a time warp. Went back to my
notes, oops, I did it again. (A famous song by Brittany Spears)
See below.
Concerning, Haralds suggestion: I don't see any problem in principle,
as long as it is recognised that both calls to has_class_alloc_comp
are negated and so types with class pointer components get through the
gate. gfc_deallocate_alloc_comp_no_caf should ignore them but I
haven't checked.
In chunks 2 and 3, please move expr->ts.type == BT_DERIVED to the
start of the condition to guard the use of the typespec derived field
in the call to has_class_alloc_comp. It should be OK as it is but it
is worthwhile taking that extra little bit of care :-)
Done
Finally, the leaking part of pdt_86.f03 has been isolated as an
additional test. If you think that it is useful, please add it to the
patch. (Renamed to pdt_86_leak_test.f90?)
This comment not applicable. I do have a new test case for the actual leaker in
the patch.
I will commit shortly.
Thanks for reviews and patience.
Jerry
OK for mainline and backporting.
Cheers
Paul
On Tue, 23 Jun 2026 at 00:05, Jerry D <[email protected]> wrote:
On 6/22/26 1:35 PM, Harald Anlauf wrote:
Hi Jerry!
Am 22.06.26 um 8:37 PM schrieb Jerry D:
See attached patch.
Regression tested on x86_64.
A new test case is added to asan to catch this in the future.
I'd rather leave the review to Paul, but I have one question:
As is, the new helper has_class_alloc_comp might return true for
pointer components, but I think it should not.
Can you please check?
Harald, I think you are right. I changed it to this:
static bool
has_class_alloc_comp (gfc_symbol *der)
{
for (gfc_component *c = der->components; c; c = c->next)
if (c->ts.type == BT_CLASS && !c->attr.pointer)
return true;
return false;
}
I will wait for Paul to review.
Thanks..
Cheers,
Harald
OK for mainline.
Regards,
Jerry
---
fortran: Fix memory leak for array structure-constructor element [PR121972]
Fix the remaining leak in pdt_86.f03. Added a new test in asan to avoid it.
PR fortran/121972
gcc/fortran/ChangeLog:
* trans-array.cc (has_class_alloc_comp): New helper; returns true if
derived type DER has any CLASS component.
(gfc_trans_array_ctor_element): Also free allocatable components when
the element expression is EXPR_STRUCTURE, skipping types that contain
CLASS components to avoid freeing stack-allocated _data pointers.
(gfc_constructor_is_owned_alloc_comp): Likewise treat EXPR_STRUCTURE
elements as owned only when the derived type has no CLASS components.
* trans-expr.cc (gfc_trans_alloc_subarray_assign): Free allocatable
components of the component's temporary descriptor before nulling its
data pointer, for non-variable source expressions.
gcc/testsuite/ChangeLog:
* gfortran.dg/class_array_15.f03: Adjust expected free count.
* gfortran.dg/derived_constructor_comps_6.f90: Adjust expected free count.
* gfortran.dg/asan/structure_constructor_alloc_comp_leak_1.f90: New test.
---
