public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected Date: Sat, 19 Feb 2011 11:26:00 -0000 [thread overview] Message-ID: <bug-47805-4-LEU51wvIH7@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-47805-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47805 janus at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pault at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2011-02-19 10:41:13 UTC --- (In reply to comment #0) > Overriding a TBP seems to OK, if the TBP is hidden through accessibility > (PRIVATE). Huh, tricky thing. > The first example given in the file is rejected with: > > PROCEDURE,NOPASS :: p => p2 ! (2). > 1 > Error: 'p' at (1) must have the same number of formal arguments as the > overridden procedure One can get rid of this error message e.g. by ... (warning: not regtested) Index: class.c =================================================================== --- class.c (revision 170290) +++ class.c (working copy) @@ -639,21 +639,24 @@ res = gfc_find_symtree (root, name); if (res && res->n.tb && !res->n.tb->error) { - /* We found one. */ - if (t) - *t = SUCCESS; - if (!noaccess && derived->attr.use_assoc && res->n.tb->access == ACCESS_PRIVATE) { if (where) - gfc_error ("'%s' of '%s' is PRIVATE at %L", - name, derived->name, where); + { + gfc_error ("'%s' of '%s' is PRIVATE at %L", + name, derived->name, where); + return res; + } + } + else + { + /* We found one. */ if (t) - *t = FAILURE; + *t = SUCCESS; + + return res; } - - return res; } /* Otherwise, recurse on parent type if derived is an extension. */ Index: resolve.c =================================================================== --- resolve.c (revision 170290) +++ resolve.c (working copy) @@ -11194,8 +11194,8 @@ if (super_type) { gfc_symtree* overridden; - overridden = gfc_find_typebound_proc (super_type, NULL, - stree->name, true, NULL); + overridden = gfc_find_typebound_proc (super_type, NULL, stree->name, + false, NULL); if (overridden && overridden->n.tb) stree->n.tb->overridden = overridden->n.tb; However, one then gets different results than indicated in (3)-(5), i.e. gfortran always calls 'p2'. It seems our current run-time mechanisms are not able to cope with this case. The only way I can see out of this is to resolve the call in 'do_p' not to the polymorphic version 'x->_vptr->p', but to a static call to the subroutine 'p' (since 'p' is effectively not overridable, at least not outside the module). But then it gets really tricky if we put 't2' in the same module. Then 'p' *will* be overridden, and we have to get back to the dynamic vtable call again to get it right. Then be so nasty to add another type 't3' in a different module, which defines a new TBP 'p' which does *not* override t1%p. And, bang!, we're in trouble again. So, I'm clueless. Does it help to put the type-name into the binding name? Say, have the call in 'do_p' resolve to 'x->_vptr->t1_p' (to honor the fact that the base type for the call is t1).
next prev parent reply other threads:[~2011-02-19 10:41 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-02-18 17:06 [Bug fortran/47805] New: " burnus at gcc dot gnu.org 2011-02-18 17:07 ` [Bug fortran/47805] " burnus at gcc dot gnu.org 2011-02-19 11:26 ` janus at gcc dot gnu.org [this message] 2011-02-19 14:23 ` janus at gcc dot gnu.org 2012-10-01 13:49 ` burnus at gcc dot gnu.org 2015-10-13 16:55 ` dominiq at lps dot ens.fr
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-47805-4-LEU51wvIH7@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).