[Bug fortran/46662] New: [OOP] gfortran rejects CALL polymorphic%abstract_type%tbp()

[Bug fortran/46662] New: [OOP] gfortran rejects CALL polymorphic%abstract_type%tbp()

[burnus at gcc dot gnu.org]

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

           Summary: [OOP] gfortran rejects   CALL
                    polymorphic%abstract_type%tbp()
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: sfilippone@uniroma2.it, janus@gcc.gnu.org


Tracking - not yet clear whether gfortran mishandles it.

Reported by salvatore at c.l.f,
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a0857fa4a692d518#

gfortran currently rejects:

 CALL polymorphic%abstract_type%tbp()

Which seems to be valid according to the quotes from the standard (see below).
However, if it is valid, I fail to find a restriction prohibiting a call to a
deferred TBP, which has to be invalid.


R1220 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ]
R1221 procedure-designator is procedure-name
                           or proc-component-ref
                           or data-ref % binding-name

R611 data-ref is part-ref [ % part-ref ] ...
R612 part-ref is part-name [ ( section-subscript-list ) ] [ image-selector ]

C611 (R611) If the rightmost part-name is of abstract type, data-ref shall be
polymorphic.

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%tbp()

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-25 18:08:45 UTC ---
Asked at J3: http://j3-fortran.org/pipermail/j3/2010-November/004015.html

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%tbp()

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-25 18:14:23 UTC ---
Some data points: gfortran 4.6 and NAG 5.2 reject the program; Crayftn accepts
the program - but it also accepts the program with a deferred TBP - and ICEs.

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%tbp()

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 08:08:44 UTC ---
> C611 (R611) If the rightmost part-name is of abstract type, data-ref shall be
> polymorphic.

That's the key point, which makes it invalid. To quote from Malcolm Cohen's
answer:

"In your example, the "data-ref" is "polymorphic%abstract".
 You said that "abstract" was of abstract type.
 And "polymorphic%abstract" certainly is not polymorphic -
 you have selected the bit that is of type "abstract"."

Hence, the PR is invalid as gfortran and NAG properly diagnose it :-)

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%ppc()

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
            Summary|[OOP] gfortran rejects      |[OOP] gfortran rejects
                   |CALL                        |CALL
                   |polymorphic%abstract_type%t |polymorphic%abstract_type%p
                   |bp()                        |pc()

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 14:02:41 UTC ---
REOPEN:

As Wolfgang Kilian mentions in the c.l.f thread (cf. link in comment 0):
While gfortran rejects TBP, it accepts PPC (proc pointer components)

  CALL polymorphic%abstract_type%PPC()

The same arguments should hold for those, which means that they should be
rejected.

[Bug fortran/46662] [OOP] gfortran rejects CALL polymorphic%abstract_type%ppc()

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.11.26 16:01:20
     Ever Confirmed|0                           |1

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 16:01:20 UTC ---
(In reply to comment #4)
> While gfortran rejects TBP, it accepts PPC (proc pointer components)
>
>   CALL polymorphic%abstract_type%PPC()

To make it a bit clearer:

R1221 procedure-designator is ... or proc-component-ref or ...
R739  proc-component-ref is scalar-variable % procedure-component-name

where "variable" can be a "designator" which can be a "structure-component"
which is a "data-ref". Thus, we are back at C611 which tells that the
right-most part-ref (here: "abstract-type") must not be both abstract and
not-polymorphic.


For TBP the check is done in resolve.c's check_typebound_baseobject; for PPC
the check should be added at update_ppc_arglist -- few lines up.

[Bug fortran/46662] [OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |
            Summary|[OOP] gfortran rejects      |[OOP] gfortran accepts
                   |CALL                        |"CALL
                   |polymorphic%abstract_type%p |polymorphic%abstract_type%p
                   |pc()                        |pc()"

--- Comment #6 from janus at gcc dot gnu.org 2010-11-27 10:51:47 UTC ---
(In reply to comment #5)
> For TBP the check is done in resolve.c's check_typebound_baseobject; for PPC
> the check should be added at update_ppc_arglist -- few lines up.

Right. I'll take care of it ...

[Bug fortran/46662] [OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2010-11-28 18:37:58 UTC ---
I will commit the following patch as obvious:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c    (revision 167218)
+++ gcc/fortran/resolve.c    (working copy)
@@ -5389,6 +5389,14 @@ update_ppc_arglist (gfc_expr* e)
       return FAILURE;
     }

+  /* F08:C611.  */
+  if (po->ts.type == BT_DERIVED && po->ts.u.derived->attr.abstract)
+    {
+      gfc_error ("Base object for procedure-pointer component call at %L is
of"
+         " ABSTRACT type '%s'", &e->where, po->ts.u.derived->name);
+      return FAILURE;
+    }
+
   gcc_assert (tb->pass_arg_num > 0);
   e->value.compcall.actual = update_arglist_pass (e->value.compcall.actual,
po,
                           tb->pass_arg_num,

[Bug fortran/46662] [OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2010-11-28 20:22:32 UTC ---
Author: janus
Date: Sun Nov 28 20:22:29 2010
New Revision: 167225

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167225
Log:
2010-11-28  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/46662
    * resolve.c (update_ppc_arglist): Add check for abstract passed object.

2010-11-28  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/46662
    * gfortran.dg/proc_ptr_comp_pass_7.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/46662] [OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from janus at gcc dot gnu.org 2010-11-28 20:33:53 UTC ---
Fixed with r167225. Closing.