User account creation filtered due to spam.

Bug 47805 - [OOP] Overridding hidden (private) TPB is rejected
Summary: [OOP] Overridding hidden (private) TPB is rejected
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: patch, rejects-valid
Depends on:
Blocks:
 
Reported: 2011-02-18 17:00 UTC by Tobias Burnus
Modified: 2015-10-13 16:54 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-10-13 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2011-02-18 17:00:21 UTC
See http://j3-fortran.org/doc/year/11/11-141.txt and watch out for updates (11-141r1.txt etc.), approved by J3 meeting.

Overriding a TBP seems to OK, if the TBP is hidden through accessibility (PRIVATE).

Note (cf. example 2 in the IR): Abstract DT with private deferred TBP cannot be extended as one cannot implement the deferred TBP.


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


  MODULE example1_m1
    TYPE t1
    CONTAINS
      PROCEDURE,PRIVATE,NOPASS :: p ! (1).
    END TYPE
  CONTAINS
    SUBROUTINE p
      PRINT *,'p'
    END SUBROUTINE
    SUBROUTINE do_p(x)
      CLASS(t1) x
      CALL x%p
    END SUBROUTINE
  END MODULE
  MODULE example1_m2
    USE example1_m1
    TYPE,EXTENDS(t1) :: t2
    CONTAINS
      PROCEDURE,NOPASS :: p => p2 ! (2).
    END TYPE
  CONTAINS
    SUBROUTINE p2(n)
      PRINT *,'p2',n
    END SUBROUTINE
  END MODULE
  PROGRAM example1
    USE example1_m2
    TYPE(t2),TARGET :: x
    CLASS(t1),POINTER :: y
    y => x
    CALL do_p(x) ! (3): I expect this to print 'p'.
    CALL do_p(y) ! (4): I expect this to print 'p'.
    CALL x%p(13) ! (5): I expect this to print 'p2 13'.
  END PROGRAM
Comment 1 Tobias Burnus 2011-02-18 17:05:35 UTC
Forgot to link to http://j3-fortran.org/pipermail/j3/2011-February/004197.html
which is about the J3 ballot of those items; it also contains an updated version of the paper.

The IR has been approved by the J3 meeting and currently a J3 ballot is running (cf. link); if accepted, it moves on to June's WG5 meeting in Garching.
Comment 2 janus 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).
Comment 3 janus 2011-02-19 13:57:09 UTC
(In reply to comment #2)
> One can get rid of this error message e.g. by ... (warning: not regtested)

Side note: This patch does not cause any regressions in the test suite. However, it makes no sense to apply it without any run-time support for this feature (which will be less trivial to implement). Also one should probably wait for the final result of the interpretation request, which means this will probably not make it into 4.6.
Comment 4 Tobias Burnus 2012-10-01 13:48:48 UTC
Updated version: F08/0052 at ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1907.txt
(incorporated in Corrigendum 1 to F2008).
Comment 5 Dominique d'Humieres 2015-10-13 16:54:58 UTC
For what it worth, updated link in comment 1:

http://mailman.j3-fortran.org/pipermail/j3/2011-February/004197.html

The problems are still there at r228753.