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

["Paul Richard Thomas" <paul.richard.thomas@gmail.com>]

Dear All,

Dominique and Tobias have pointed out a regression caused by the
patch.  I had completely neglected renaming that is not part of an
only-list.  Since all the mechanisms are in place to get this right, I
propose to spend 48hours on it and to update from here.  I have one
version of a patch regtesting right now but will need to examine it
very carefully against all the possible conditions.

Sorry that this is not right first go but it is quite complex!

Cheers

Paul

On Nov 22, 2007 4:44 PM, 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