This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/44978] derived types are resolved more than once


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to janus from comment #9)
> (In reply to Mikael Morin from comment #8)
> > > @@ -11962,6 +11957,10 @@ resolve_fl_derived0 (gfc_symbol *sym)
> > >    gfc_symbol* super_type;
> > >    gfc_component *c;
> > >  
> > > +  if (sym->resolved>1)
> > > +    return true;
> > > +  sym->resolved = 2;
> > > +
> > >    if (sym->attr.unlimited_polymorphic)
> > >      return true;
> > 
> > The first time we hit the function, sym->resolved is set to 2.
> > Suppose that an error is issued, and the function returns false.
> > Then, on the next time the function is called with the same symbol argument,
> > no error is issued (this is the purpose of the patch), but as a side effect
> > the function will return true, so that the caller will proceed as if the
> > symbol was well formed.
> 
> That's true, but I'm not sure that it is really a problem (at least the
> gfortran testsuite does not seem to have a problem with it).
> 
Well if that's not a problem, then the return value is not useful or at least
not a used in a way that impacts the compiler so it can as well be void.

> Do you have a simple idea how to improve the patch in this regard?
The first one that comes to mind (beyond changing the return type to void) is
caching the return value(s) in the symbol, one for each procedure.

Another possibility: change the code to:

  if (sym->resolved>1)
    return false;

  old_resolved = sym->resolved;
  sym->resolved = 2;

  /* blah... */

  sym->resolved = old_resolved;
  return true;
}


This only avoids the duplicate errors.  Multiple resolutions still happens when
they are successful (which is the common case unfortunately).

> Or can
> you give an example where it would create a problem?

No, it was more a general design comment. I will try to find one.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]