UDDTIO: issues with PRIVATE and PUBLIC attributes on bound procedures and generic bindings

[FortranFan]

Consider this thread - https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/698147 - where a simple example based on Note 9.48 in the Fortran 2008 working document is shown.  Except for some potential confllict with some compiler option(s), the code as shown works ok with compiler 17.  Note the default attribute for type-bound procedures in the example is PUBLIC which is what would apply to the generic binding for the defined derived type formatted write as well.

Now consider a slight variation where the default attribute is modified to PRIVATE and the PUBLIC attribute is explicitly applied to the generic binding.  As far as I can tell looking at the standard, the code is ok but Intel Fortran compiler 17 throws an error which I think is incorrect.  gfortran (GCC 7.0 development trunk that just recently has added the UDDTIO facility) compiles and works with the code.

module m

   implicit none

   type :: person
      character (len=20) :: name
      integer :: age
   contains
      private
      procedure :: pwf
      generic, public :: write(formatted) => pwf
   end type person

contains

   subroutine pwf (dtv,unit,iotype,vlist,iostat,iomsg)

      ! argument definitions
      class(person), intent(in)        :: dtv
      integer, intent(in)              :: unit
      character (len=*), intent(in)    :: iotype
      integer, intent(in)              :: vlist(:)
      integer, intent(out)             :: iostat
      character (len=*), intent(inout) :: iomsg

      ! local variable
      character (len=9) :: pfmt

      ! vlist(1) and (2) are to be used as the field widths of the two
      ! components of the derived type variable. First set up the format to
      ! be used for output.
      write(pfmt,'(A,I2,A,I2,A)', iostat=iostat, iomsg=iomsg ) '(A', vlist(1), ',I', vlist(2), ')'
      if (iostat /= 0) return

      ! now the basic output statement
      write(unit, fmt=pfmt, iostat=iostat, iomsg=iomsg) dtv%name, dtv%age
      if (iostat /= 0) return

      return

   end subroutine pwf

end module m

Compiling with Intel(R) Visual Fortran Compiler 17.0.0.109 [Intel(R) 64]...
m.f90
m.f90(11): error #5082: Syntax error, found IDENTIFIER 'FORMATTED' when expecting one of: = .EQV. .NEQV. .XOR. .OR. .AND. .LT. < .LE. <= .EQ. == .NE. /= .GT. > ...
m.f90(11): error #6268: The keyword ASSIGNMENT or OPERATOR was expected in this context.   [WRITE]
m.f90(16): remark #7712: This variable has not been used.   [IOTYPE]
ifort: error #10298: problem during post processing of parallel object compilation
compilation aborted for m.f90 (code 1)

[Steven_L_Intel1]

We'll check it out.

[Steven_L_Intel1]

Yep, this is a simple bug in the parsing that doesn't expect this combination. Escalated as issue DPD200414836. Thanks.

[FortranFan]

Steve Lionel (Intel) wrote:

Yep, this is a simple bug in the parsing that doesn't expect this combination. Escalated as issue DPD200414836. Thanks.

Steve,

Thanks.

By the way, if "this is a simple bug in the parsing", can a "quick" fix be possible?  

As I mentioned in the original post, with the introduction of UDDTIO in gfortran, we were hoping to further explore and test out this standard Fortran feature in Intel Fortran with gfortran as a guide.  Since almost all the derived type cases in test consideration have PRIVATE as the default attribute for type bound procedures, we can't proceed without a whole bunch of changes.  Hence it will help us greatly if we are able to quickly apply the PUBLIC attribute on the generic bindings for derived type IO, as shown with the code in the original post.

Separately, is it for Intel Fortran team to consider rolling patches (in some continuous delivery mode) for "simple" bug fixes (if there is such a thing!) or completed standards related revisions following interps, so one does not have to wait several months or possibly even longer for updates?

Typically the window of attention is rather limited and once it passes, it's rather difficult to come back - previously, I'd looked in PDTs and several DP issues were escalated as a result, but the wait for resolution was longer than the development time window and the opportunity to make use of PDTs in some of the code was lost.

Thanks,

[Steven_L_Intel1]

Sorry, we don't have a mechanism in place for "rolling updates". We can provide engineering builds on a case-by-case basis, but it requires several levels of management approval.