Thanks Gents! The solution is to gfc_free_expr (p) if the replacement is not made.
I am regtesting a patch for PR107900. I'll include the fix for the memory leak in the patch for that. Cheers Paul On Thu, 8 Jun 2023 at 09:30, Harald Anlauf <anl...@gmx.de> wrote: > > On 6/8/23 09:46, Mikael Morin wrote: > > Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit : > >> Hi Harald, > >> > >> In answer to your question: > >> void > >> gfc_replace_expr (gfc_expr *dest, gfc_expr *src) > >> { > >> free_expr0 (dest); > >> *dest = *src; > >> free (src); > >> } > >> So it does indeed do the job. > >> > > Sure, but his comment was about the case gfc_replace_expr is *not* > > executed. > > Right. The following legal code exhibits the leak, pointing > to the gfc_copy_expr: > > subroutine paul (n) > integer :: n > character(n) :: c > end > > >> I should perhaps have remarked that, following the divide error, > >> gfc_simplify_expr was returning a mutilated version of the expression > >> and this was somehow connected with successfully simplifying the > >> parentheses. Copying and replacing on no errors deals with the > >> problem. > >> > > Is the expression mutilated enough that it can't be safely freed? > > > > > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein