Re: [Patch, fortran] PR33541 - gfortran wrongly imports renamed-use-associated symbol unrenamed

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

Please hold this for 24 hours - there is one regression in the final
version that I had failed to notice.

Paul

On 11/22/07, Paul Richard Thomas <paul.richard.thomas@gmail.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'.
>
> Paul
>
>


-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy