On Sun, 7 Nov 2021 13:32:34 +0100 Mikael Morin <morin-mik...@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). 1) 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; conflict: + /* 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);