Bug 46662 - [OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"
[OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: ---
Assigned To: janus
: rejects-valid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-25 18:04 UTC by Tobias Burnus
Modified: 2010-11-28 20:33 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-11-26 16:01:20


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2010-11-25 18:04:29 UTC
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.
Comment 1 Tobias Burnus 2010-11-25 18:08:45 UTC
Asked at J3: http://j3-fortran.org/pipermail/j3/2010-November/004015.html
Comment 2 Tobias Burnus 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.
Comment 3 Tobias Burnus 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 :-)
Comment 4 Tobias Burnus 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.
Comment 5 Tobias Burnus 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.
Comment 6 janus 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 ...
Comment 7 janus 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,
Comment 8 janus 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
Comment 9 janus 2010-11-28 20:33:53 UTC
Fixed with r167225. Closing.