Dear all,
the attached patch fixes a front-end memleak that is seen when
running f951 under valgrind and while parsing invalid uses of
NULLIFY.
I had this in my tree for some time without any problems, in an
attempt to further reduce leaks that obscure more significant
front-end issues, but am only submitting now after re-regtesting
on x86_64-pc-linux-gnu.
I will commit as obvious within 24 hours unless there are comments.
Thanks,
Harald
From 35adb4c16aaaf89dae78e2c494998043a14099b2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anl...@gmx.de>
Date: Sat, 1 Mar 2025 15:42:57 +0100
Subject: [PATCH] Fortran: fix front-end memleak after failure during parsing
of NULLIFY
gcc/fortran/ChangeLog:
* match.cc (gfc_match_nullify): Free matched expression when
cleaning up.
* primary.cc (match_variable): Initialize result to NULL.
---
gcc/fortran/match.cc | 1 +
gcc/fortran/primary.cc | 2 ++
2 files changed, 3 insertions(+)
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index c3c330520d6..ec9e5873204 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5071,6 +5071,7 @@ cleanup:
new_st.expr1 = NULL;
gfc_free_expr (new_st.expr2);
new_st.expr2 = NULL;
+ gfc_free_expr (p);
return MATCH_ERROR;
}
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 8a38720422e..161d4c26964 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4298,6 +4298,8 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
locus where, old_loc;
match m;
+ *result = NULL;
+
/* Since nothing has any business being an lvalue in a module
specification block, an interface block or a contains section,
we force the changed_symbols mechanism to work by setting
--
2.43.0
