This is the mail archive of the 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]

Re: [Patch, fortran] PR24558, PR20877 and PR25047 - module function alternate entries.

Paul Thomas <> wrote on Fri, 09 Jun 2006:
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.

Thanks for the explanation. The patch is ok, but I would welcome a comment in a strategically chosen place (resolve_entries is probably the right place). Oh, and don't forget about that redundant if :-)

- Tobi

This message was sent using IMP, the Internet Messaging Program.

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