Possible bug using OPTIONAL in F2003 abstract interfaces

I am trying to define a pointer procedure with optional arguments inside a derived datatype, using an abstract interface. The desired behavior is to use the procedure pointer to switch routines on the fly, if necessary.

Unfortunately, it seems that it is not possible to use optional arguments in Fortran abstract interfaces. The following code fails to compile using either pgfortran 18.10 or 19.10, but compiles with gfortran or ifort.

Compilation error is as follows:

$ pgfortran -c option.f90
PGF90-S-0188-Argument number 2 to proc_opts: type mismatch (option.f90: 40)
  0 inform,   0 warnings,   1 severes, 0 fatal for use_opts

Source is shown below…

module optional_mod

  type foo
     real :: bar
     procedure(sopt), pointer, pass(this) :: proc_opts
     procedure      , pass(this) :: use_opts
     procedure      , pass(this) :: dummy_routine
  end type foo

  abstract interface
     subroutine sopt(this,lopt)
       import foo
       implicit none
       class(foo) :: this
       logical, optional, intent(in) :: lopt
     end subroutine sopt
  end interface


  ! Constructor
  subroutine init(this)
    implicit none
    class(foo) :: this

    !Initialize the procedure pointer
    this%proc_opts => dummy_routine
  end subroutine init

  ! Call procedure pointer without optional argument
  subroutine use_opts(this)
    implicit none
    class(foo) :: this

    call this%proc_opts()
  end subroutine use_opts

  ! Dummy routine
  subroutine dummy_routine(this,lopt)
    implicit none
    class(foo)                    :: this
    logical, optional, intent(in) :: lopt

    if (present(lopt)) then
       write (*,*) "Optional parameter present"
       write (*,*) "Optional parameter not present"
    end if
  end subroutine dummy_routine
end module optional_mod

It is quite possible that this problem can be circumvented by duplicating the routines and using an interface to differentiate between them, but I haven’t tried that yet.

Thank you for your help!

This looks like a bug in our compiler. We are tracking this as FS#28361.

Thank you!