Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Naming trouble

Emil_S_
Beginner
910 Views

Hi The following code does not compile with ifort 14.0.3, but compiles and works fine with gfortran(4.6, 4.7 and 4.8).

module ab_mod
  type :: a
   contains
     procedure :: proc1
     procedure :: proc2
     generic :: proc => proc1, proc2
  end type a

  type :: b
     class(a), pointer :: a
  end type b

contains
  subroutine proc1(this, val)
    implicit none
    class(a) :: this
    integer, intent(out) :: val
    val=1
  end subroutine proc1

  subroutine proc2(this, val)
    implicit none
    class(a) :: this
    real, intent(out) :: val
    val=1.0
  end subroutine proc2
end module ab_mod

program test
  use ab_mod

  type(a), target :: a_obj
  type(b) :: b_obj
  integer :: val

  b_obj%a => a_obj

  call a_obj%proc(val)
  print *, val
  call b_obj%a%proc(val)
  print *, val
  call b_obj%a%proc1(val)
  print *, val
end program test

Ifort complains that

test.f90(40): error #8486: There is no matching specific subroutine for this type bound generic subroutine call.   [PROC]
  call b_obj%a%proc(val)
---------------^
compilation aborted for test.f90 (code 1)

The problem centers around the naming of the class(a) component of type b. If I change type b to

type :: b
class(a), pointer :: a_obj
end type b

and make the necessary changes to the program-section, the code compiles and runs fine with ifort. The question is, is it illegal to use the original naming? If so, why does ifort not complain a line 10? And why does it complain at line 40, and not 42?

Best regards

Emil Sørensen

0 Kudos
5 Replies
FortranFan
Honored Contributor III
910 Views

Clearly a bug.  It exists in my Ifort 15 beta version too.  But I'm surprised to see this error because I do make use of a somewhat similar construct in one of my codes and it seems to work ok there.

0 Kudos
Steven_L_Intel1
Employee
910 Views

Thanks, we'll take a look. This one sounds familiar...

0 Kudos
Steven_L_Intel1
Employee
910 Views

This has been escalated as issue DPD200256512. It's legal to have the original code with the names being the same - type names and component names are in different "classes" of local names. Thanks for the nice example.

0 Kudos
Emil_S_
Beginner
910 Views

All right, thank you for your responses. I'm just glad I could help.

0 Kudos
Steven_L_Intel1
Employee
910 Views

This has been fixed for the 15.0 release later this year.

0 Kudos
Reply