This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR24558, PR20877 and PR25047 - module function alternate entries.
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: tobias dot schlueter at physik dot uni-muenchen dot de
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, patch <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 09 Jun 2006 07:05:17 +0200
- Subject: Re: [Patch, fortran] PR24558, PR20877 and PR25047 - module function alternate entries.
- References: <447D6C10.firstname.lastname@example.org> <email@example.com>
I think yes with the change we discussed before, but I'm not sure I
understand what the change to resolve_entries really does. How can
we end up there with the wrong namespace?
This comes back to the original problem: Unlike a subroutine entry, the
function entry can have references that appear before the entry
statement. The fix proceeds by leaving the symtree in the function
namespace, as if this were an external, rather than a module function.
This results in a usable, in the module sense, symbol that is completely
resolved. However, the fake return value mechanism is broken at this
stage because the ns field has not been fixed up. This is what the
change to resolve_entries does.
I did start work on this patch, before Christmas, by removing the
symtree from the function namespace and putting it in the module
namespace. This got very messy and there were considerably more fixes
needed down-stream. There was a light bulb moment a couple of weeks
back, when I realised that I must be able to get it to work like an
external function. This slightly awkward fix with the namespace is the
price paid for simplicity elsewhere.
I will await your final OK before committing.