[PATCH,FORTRAN] Fix memory leak in finalization wrappers

Bernhard Reutner-Fischer rep.dot.nop@gmail.com
Sun Nov 14 19:53:09 GMT 2021

On Sun, 7 Nov 2021 13:32:34 +0100
Mikael Morin <morin-mikael@orange.fr> wrote:

> > btw.. Just because it's vagely related.
> > I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for
> > PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761)
> > is incomplete in that i think all the internal class helpers should be
> > flagged artificial. All these symbols built in gfc_build_class_symbol,
> > generate_finalization_wrapper, gfc_find_derived_vtab etc.
> > Looking at the history it seems the artificial bit often was forgotten.  
> I guess so, yes...
> > And most importantly i think it is not correct to ignore artificial in
> > gfc_check_conflict!
> >   
> Well, it’s not correct to throw errors at users for things they haven’t 
> written and that they don’t control.

oops, i forgot to add the hunk to the patch to drain complaints to
the user 1).

Of course we don't want the error to be user-visible, but i think we do
want to check_conflicts (e.g. gfortran.dg/pr95587.f90 regresses via an
unspecific Unclassifiable statement; I assume we should copy all or at
least some sym attribs to the corresponding CLASS_DATA attribs which i
think makes sense for consistency anyway).

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 1a1e4551355..9df23f314df 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -898,6 +898,10 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
   return true;
+  /* It would be wrong to complain about artificial code.  */
+  if (attr->artificial)
+    return false;
   if (name == NULL)
     gfc_error ("%s attribute conflicts with %s attribute at %L",
 	       a1, a2, where);

More information about the Gcc-patches mailing list