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 .
next prev 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: linkBe 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).