Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Potential Procedure Pointer Bug

Matthew_C_5
Beginner
531 Views

I am trying to define a simple procedure pointer with interface, but the code does not compile with ifort 12.1.5; however, it does compile and run with gfortran 4.6.3.

test.F90:

[fortran]

MODULE test_m

IMPLICIT NONE

TYPE,PUBLIC :: test

  PROCEDURE(test1),POINTER :: test1ptr

END TYPE test

ABSTRACT INTERFACE

  SUBROUTINE test1(THIS)

    IMPORT

    IMPLICIT NONE

    CLASS(test),INTENT(IN) :: THIS

  END SUBROUTINE test1

END INTERFACE

PUBLIC :: temp

CONTAINS

  SUBROUTINE temp(THIS)

    IMPLICIT NONE

    CLASS(test),INTENT(IN) :: THIS

    WRITE (*,*) 'Hello world from the object!'

  END SUBROUTINE temp

END MODULE test_m

[/fortran]

main.F90


[fortran]

PROGRAM helloworld

USE test_m

TYPE(test) :: tester

tester%test1ptr => temp

CALL tester%test1ptr()

END PROGRAM helloworld

[/fortran]

Ifort gives the following error when trying to compile test.F90 with ifort -c test.F90:

test.F90(6): error #6404: This name does not have a type, and must have an explicit type.   [TEST1PTR]
  PROCEDURE(test1),POINTER :: test1ptr
------------------------------^
compilation aborted for test.F90 (code 1)

Once again, the code compiles and runs with gfortran. Note: if you go back through test.F90 and remove passing, e.g., define the procedure pointer with NOPASS, take away THIS in the interface, etc. it will compile. It's hard for me to believe that a simple PASS would not be allowed!

0 Kudos
2 Replies
Kevin_D_Intel
Employee
531 Views
I reproduced the error with the 12.1 compiler (XE 2011 12.1.7.367) but not with the more recent XE 2013 (13.0.1.117) compiler. If it is possible, could you upgrade to the newer release?
0 Kudos
Kevin_D_Intel
Employee
531 Views
I found two previous related internal reports (DPD200154928, DPD200177491) and one forum report: http://software.intel.com/en-us/forums/showthread.php?t=84152. I confirmed there is an explicit fix in the 13.0 compiler and also if you are able to use this, the error is avoidable with the work around of removing/de-activating the implicit none inside the abstract interface in subroutine test1.
0 Kudos
Reply