[PATCH,FORTRAN] Fix memory leak in finalization wrappers
Sun Nov 14 19:53:09 GMT 2021
On Sun, 7 Nov 2021 13:32:34 +0100
Mikael Morin <firstname.lastname@example.org> 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
@@ -898,6 +898,10 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
+ /* 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