This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, OOP] PR 56261: seg fault call procedure pointer on polymorphic array

Janus Weil:
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:

I concur.

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:

  implicit none
  type :: nc
  end type
  class    (nc), allocatable :: c
  procedure(), pointer     :: f => ff
  call f(c)
  subroutine ff (self)
    TYPE(nc) :: self
  end subroutine

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 ( 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]