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

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

: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

Attachment: Change.Logs
Description: Text document

Attachment: pr33541.diff
Description: Text document