This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR20880 - Failure to detect procedures encompassing own interface
- From: Brooks Moses <brooks dot moses at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: fortran at gcc dot gnu dot org
- Date: Mon, 27 Nov 2006 11:02:19 -0800
- Subject: Re: [Patch, fortran] PR20880 - Failure to detect procedures encompassing own interface
- References: <email@example.com>
Paul Richard Thomas wrote:
"Two or more accessible entities, other than generic interfaces or
defined operators, may have the same
identifier only if the identifier is not used to refer to an entity in
the scoping unit. Generic interfaces and
defined operators are handled as described in section 16.2.3. Except for
these cases, the local identifier
of any entity given accessibility by a USE statement shall differ from
the local identifiers of all other
entities accessible to the scoping unit through USE statements and
At the moment I fail to see whether this allows or forbids it.
The key is the "not used to refer to" in the first sentence. Clearly
two modules can contain any amount of ambiguity and, indeed, must be
able to do so, just as long as the ambiguous symbols are not referred
I agree. I recall having a conversation with Richard Maine about some
particularly twisted edge case related to this, which I remember as
confirming that this was allowed, though his advice (about the edge
case) was also "Don't do that, even though it's legal." :)
I believe that the test should include && sym->referenced. I will
check this tonight and will commit under the obvious rule if it's OK.
What does this do in the case where whether the symbol is referenced is
unknown at compile-time? For instance, in Grigory's example module the
symbol isn't referenced, but it's exported and could be referenced in
some program that includes the module and is compiled later.