This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR33541 - gfortran wrongly imports renamed-use-associated symbol unrenamed
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: gcc-patches <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Thu, 22 Nov 2007 17:08:16 +0100
- Subject: Re: [Patch, fortran] PR33541 - gfortran wrongly imports renamed-use-associated symbol unrenamed
- References: <firstname.lastname@example.org>
Please hold this for 24 hours - there is one regression in the final
version that I had failed to notice.
On 11/22/07, Paul Richard Thomas <email@example.com> wrote:
> :ADDPATCH fortran:
> This turned out to be a bit of a sweat. The PR report describes how
> USE my_module
> USE my_module, ONLY: xrename => x
> would lead to x and xrename being available in the scope of the USE
> statements. This is contrary to 11.3.2 of the standard. Being a bear
> of little brain, I find this part of the standard to be quite obscure
> and much prefer the description of the DEC Fortran manual:
> << If more than one USE statement for a given module appears in a
> scoping unit, the following rules apply:
> If one USE statement does not have the ONLY option, all public
> entities in the module are accessible, and any rename- lists and
> only-lists are interpreted as a single, concatenated rename-list.
> If all the USE statements have ONLY options, all the only-lists are
> interpreted as a single, concatenated only-list. Only those entities
> named in one or more of the only-lists are accessible. >>
> This is what I have implemented here for ordinary symbols and generic
> interfaces. The former was easy but generic interfaces turned out to
> be a complete pain. I did not have the intestinal fortitude to move
> on to operators.
> In the case of ordinary symbols, all the action takes place in
> 'read_module'. 'find_symbol' was written to find a symtree that
> refers to a given symbol name and module. If this is found for a USE
> without an ONLY clause and the found symbol was in an only-list, the
> new symbol is not added. When the new symbol is in a use-list and
> the existing symbol was not, the symtree for the existing symbol is
> renamed in such a way as to make it inaccessible. Note, renaming the
> symtree to the new, local-name does not work because its location in
> the tree will, in general, not be correct. Whilst it would be
> possible to delete the symtree and recycle the symbol, the method
> adopted here is simple and only costs the inaccessible symtree/symbol.
> For generic interfaces, the same method is used to fix the PR.
> However, this was made much more dificult by something that I had
> encountered before and had compeletly forgotten: renaming of generic
> interfaces did so to the symtree and the symbol. That is to say, the
> use-name is completely lost, making a search for the symbol by
> use-name "slightly impossible". Thus, most of the work in
> 'load_generic_interfaces' was associated with setting the symtree to
> the local_name and the sym to the use-name.
> The testcase has three parts: a test that the original problem is
> fixed, a test of its extension to generic interfaces and a check that
> renaming to the original name in an only-list does not result in the
> symbol being treated as if it were not in an only-list. Needless to
> say, an intermediate version of the patch failed in this regard!
> Bootstrapped and regtested on x86_ia64/FC5 - OK for trunk?
> Whilst being reviewed, I will check it out on tonto-2.3 and one or two
> of the other 'usual suspects'.
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy