On Tue, 16 Nov 2021 21:46:32 +0100
Harald Anlauf via Fortran <fortran@gcc.gnu.org> wrote:
> Hi Bernhard,
>
> I'm trying to understand your patch. What does it really try to solve?
Compiler generated symbols should be marked artificial.
The fix for PR88009 ( f8add009ce300f24b75e9c2e2cc5dd944a020c28 ,
r9-5194 ) added artificial just to the _final component and left out all the
rest.
Note that the majority of compiler generated symbols in class.c
already had artificial set properly.
The proposed patch amends the other generated symbols to be marked
artificial, too.
The other parts fix memory leaks.
>
> PR88009 is closed and seems to have nothing to do with this.
Well it marked only _final as artificial and forgot to adjust the
others as well.
We can remove the reference to PR88009 if you prefer?
thanks!
>
> Harald
>
> Am 14.11.21 um 23:17 schrieb Bernhard Reutner-Fischer via Fortran:
> > Hi!
> >
> > Amend fix for PR88009 to mark all these class components as artificial.
> >
> > gcc/fortran/ChangeLog:
> >
> > * class.c (gfc_build_class_symbol, generate_finalization_wrapper,
> > (gfc_find_derived_vtab, find_intrinsic_vtab): Use stringpool for
> > names. Mark internal symbols as artificial.
> > * decl.c (gfc_match_decl_type_spec, gfc_match_end): Fix
> > indentation.
> > (gfc_match_derived_decl): Fix indentation. Check extension level
> > before incrementing refs counter.
> > * parse.c (parse_derived): Fix style.
> > * resolve.c (resolve_global_procedure): Likewise.
> > * symbol.c (gfc_check_conflict): Do not ignore artificial symbols.
> > (gfc_add_flavor): Reorder condition, cheapest first.
> > (gfc_new_symbol, gfc_get_sym_tree,
> > generate_isocbinding_symbol): Fix style.
> > * trans-expr.c (gfc_trans_subcomponent_assign): Remove
> > restriction on !artificial.
> > * match.c (gfc_match_equivalence): Special-case CLASS_DATA for
> > warnings.
> >
> > ---
> > gfc_match_equivalence(), too, should not bail-out early on the first
> > error but should diagnose all errors. I.e. not goto cleanup but set
> > err=true and continue in order to diagnose all constraints of a
> > statement. Maybe Sandra or somebody else will eventually find time to
> > tweak that.
> >
> > I think it also plugs a very minor leak of name in gfc_find_derived_vtab
> > so i also tagged it [PR68800]. At least that was the initial
> > motiviation to look at that spot.
> > We were doing
> > - name = xasprintf ("__vtab_%s", tname);
> > ...
> > gfc_set_sym_referenced (vtab);
> > - name = xasprintf ("__vtype_%s", tname);
> >
> > Bootstrapped and regtested without regressions on x86_64-unknown-linux.
> > Ok for trunk?
> >
>
>
