This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran, OOP] PR 56261: seg fault call procedure pointer on polymorphic array
- From: Tobias Burnus <burnus at net-b dot de>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 07 Apr 2013 20:30:20 +0200
- Subject: Re: [Patch, Fortran, OOP] PR 56261: seg fault call procedure pointer on polymorphic array
- References: <CAKwh3qiaKALyvJnMHrGMo1P0suzxim+CXy=9VykJ1DRfN1hb5g at mail dot gmail dot com>
here is a patch for an accepts-invalid problem: The Fortran standard
demands that a procedure with a polymorphic dummy arguments can only
be referenced with an explicit interface (see F08:18.104.22.168).
It is nontrivial to detect this in every case (e.g. passing a TYPE
actual to a CLASS formal arg), but at least we can easily detect it if
a polymorphic *actual* argument is involved (which means that the
corresponding formal arg must also be polymorphic).
Sorry, I cannot follow here. At least at a glance, I don't see why the
following program is invalid:
type :: nc
class (nc), allocatable :: c
procedure(), pointer :: f => ff
subroutine ff (self)
TYPE(nc) :: self
I don't see a reason why an explicit interface should be required - and
passing a CLASS to a TYPE is also fine: "The dummy argument shall be
type compatible with the actual argument. If the actual argument is a
polymorphic coindexed object, the dummy argument shall not be polymorphic."
There is the restriction (22.214.171.124) that "A nonpolymorphic entity is type
compatible only with entities of the same declared type." but in this
example TYPE and CLASS have the same (declared) type.
Thus, the only place where the check can be is for:
f => ff
In your example, the explicit interface of "ff" is known thus it should
be testable at resolution time of the proc-pointer assignment.