public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bardeau at iram dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/51268] [Regression] A subroutine can not know anymore its own interface
Date: Thu, 24 Nov 2011 14:14:00 -0000	[thread overview]
Message-ID: <bug-51268-4-UBjsqZTXhf@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-51268-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51268

--- Comment #6 from Sebastien Bardeau <bardeau at iram dot fr> 2011-11-24 13:23:18 UTC ---
(In reply to comment #5)

> It should be buried in "16 Scope, association, and definition", but I need some
> time to extract it.

Ok, so did I. Here is what I can read section 16.2, p.406 (shortened):

"Within a scoping unit, identifiers of entities in the following classes:
(1) ..., abstract interfaces, generic interfaces, ...
are local identifiers in that scoping unit.
Within a scoping unit, a local identifier of an entity of class (1) shall not
be the same as a global identifier used in that scoping unit."

There is no explicit rule regarding the "specific interfaces" which we are
interested in since the beginning.

Furthermore, section 12.3.2.1, p.260 + corrigendum 5:
"A procedure shall not have more than one explicit specific interface in a
given scoping unit, except that if the interface is accessed by use
association, there may be more than one local name for the procedure".
As far as I understand, specific interface names accessed by use-association do
not conflict with the procedure name itself. Isn't it a key point in our
discussion?


> You could also ask at the comp.lang.fortran newsgroup where
> (among others) the editor of the Fortran 2003 standard answers such questions.
Yes it will be interesting to have their point of view depending on how we
finally agree on the standard interpretation.

Thanks for your other explanations and examples, I keep them in mind for
further discussions, here or on the comp.lang.fortran newsgroup .


  parent reply	other threads:[~2011-11-24 13:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22 13:32 [Bug fortran/51268] New: " bardeau at iram dot fr
2011-11-22 16:42 ` [Bug fortran/51268] " burnus at gcc dot gnu.org
2011-11-23  9:34 ` bardeau at iram dot fr
2011-11-23 10:54 ` burnus at gcc dot gnu.org
2011-11-23 14:20 ` bardeau at iram dot fr
2011-11-23 17:17 ` burnus at gcc dot gnu.org
2011-11-24 14:14 ` bardeau at iram dot fr [this message]
2011-11-24 14:45 ` burnus at gcc dot gnu.org
2011-11-24 16:35 ` bardeau at iram dot fr
2011-11-29 14:29 ` burnus at gcc dot gnu.org
2011-11-29 14:48 ` bardeau at iram dot fr
2011-11-29 15:24 ` burnus at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-51268-4-UBjsqZTXhf@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).