Problem with procedure pointers using both ifx and ifort

[GreenScreen]

The following code sample, that I came across in an older code, doesn't compile with both ifx and ifort, although it does with both Gfortran 11 and (classic) Flang.

module fails

   implicit none

   type, abstract :: dtype
      procedure(dummy_sub), nopass, pointer :: ptr => null()
   end type dtype
   
   abstract interface
      subroutine dummy_sub( )
      end subroutine dummy_sub
   end interface
   
contains
   
   subroutine dummy( )
      return
   end subroutine dummy

   function check(obj) result(n)      
      class(dtype), intent(in) :: obj
      integer(4) :: n      
      if ( associated(obj%ptr, dummy) ) then
         n = 1
      else
         stop 'Pointer not associated!'
      end if
   end function check
   
end module fails

The error message from ifx (and ifort) is the following:

fails.f90(23): error #6424: This name has already been used as an external subroutine name. [DUMMY]
if ( associated(obj%ptr, dummy) ) then
-------------------------------^
fails.f90(23): error #8191: The procedure target must be a procedure or a procedure pointer. [ASSOCIATED]
if ( associated(obj%ptr, dummy) ) then
-------------------------------^
compilation aborted for fails.f90 (code 1)

The error message is rather unclear ("dummy" is a module procedure, not an external one). It's not clear to me why "dummy" isn't allowed to appear as a target in the "associated" intrinsic function. As far as I can tell, even ifort versions of several years ago won't compile the above code sample.

[FortranFan]

For whatever it's worth, my take is Intel Fortran is in the wrong here to raise errors while the code conforms to the standard.

@GreenScreen , if you have a support subscription with Intel, please submit a service request at the Intel Online Service Center (OSC).  Otherwise, you can wait for someone from the Intel team to review this thread and for them to submit a request for you. 

Since it may take a while for a resolution to this issue in a future release of the Intel Fortran compilers, you can give the following workaround a try and see if it works in your code (untested as I post this from my child's iPad during vacation):

   function check(obj) result(n)      
      class(dtype), intent(in) :: obj
      integer(4) :: n
      procedure(dummy_sub), pointer :: lptr  !<--  employ a local object as workaround 
      lptr => obj%ptr 
      if ( associated(lptr, dummy) ) then
         n = 1
      else
         stop 'Pointer not associated!'
      end if
   end function check

[GreenScreen]

@FortranFan, Thanks for your reply.

Unfortunately, I don't have a support subscription, so I hope someone from Intel can take care of submitting a service request, so that we can ultimately get a bug fix for that.

Not that I'd personally recommend the use of procedure pointers, but there are codes out there that use them. Trying to compile the particular code that I've mentioned above, I've already hit this particular bug multiple times, so trying to work around it is tedious.

[FortranFan]

Re: "Not that I'd personally recommend the use of procedure pointers," you will note procedure pointers are quite useful for developing flexible libraries that can work with consumer-supplied methods for certain tasks on hand.  As such they can prove safer than the use of the `EXTERNAL` statement with codes based in FORTRAN 77 and related but nonstandard dialects.  And there are quite a few long running codes out there with EXTERNAL indicating both the need for and utility of this.  Thus the procedure pointer facility in the language and robust, reliable implementations in compilers such as Intel Fortran are only par for the course.

[Ron_Green]

We do accept bug reports here on this Forum. 

I'll get a bug opened on this one.  It is one we'd like to fix soon. 

Ron

[GreenScreen]

Great!

Thank you.

[Ron_Green · Accepted solution]

Bug ID CMPLRLLVM-43122