This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ICE on functions with no explicit nor implicit type (PR fortran/21729)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Tobias Schlueter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Sat, 28 May 2005 10:20:27 -0400
- Subject: Re: [PATCH] Fix ICE on functions with no explicit nor implicit type (PR fortran/21729)
- References: <20050524213510.GS4930@devserv.devel.redhat.com> <429876D5.7000204@physik.uni-muenchen.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sat, May 28, 2005 at 03:49:09PM +0200, Tobias Schl?ter wrote:
> Ok, but I have one question about the following hunk. I'd also prefer if you
> made that hunk a function which is then called from gfc_resolve to stay in
> line with the concept that gfc_resolve outlines the operations necessary for
> resolution.
Ok, will do.
>
> > @@ -4835,6 +4842,39 @@ gfc_resolve (gfc_namespace * ns)
> >
> > gfc_traverse_ns (ns, resolve_symbol);
> >
> > + if (ns->proc_name && ns->proc_name->attr.function)
> > + {
> > + gfc_entry_list *el;
> > + gfc_symbol *sym;
> > +
> > + if (ns->entries)
> > + sym = ns->entries->sym;
> > + else
> > + sym = ns->proc_name;
>
> Why this if? Did you run into a bug when you tried to resolve the function
> symbol itself?
I just wanted to print Function for functions and ENTRY for their entries.
If it just printed Function always it could be slightly simpler.
Jakub