associate contruct vs. accessing directly the type components

[MR]

Hi,

I am unable to compile the following code:

$ ifort -c tst.f90

tst.f90(27): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.   [AT1]

   call at1%set_x()

--------^

compilation aborted for tst.f90 (code 1)

Using the complete reference  a%p%set_x()  instead of the associate construct works. Is this the correct behaviour or an error by ifort?

module m
 implicit none

 type :: t1
  real :: x
 contains
  procedure, pass(var) :: set_x
 end type t1

 type :: t2
  type(t1), pointer :: p => null()
 end type t2

contains

 pure subroutine set_x(var)
  class(t1), intent(inout) :: var
   var%x = 2.0
 end subroutine set_x

 subroutine s(a)
  type(t2), intent(in) :: a

   !call a%p%set_x() ! accepted

   associate( at1 => a%p ) ! not accepted
   call at1%set_x()
   end associate

 end subroutine s

end module m

[FortranFan]

MR wrote:

..

Using the complete reference  a%p%set_x()  instead of the associate construct works. Is this the correct behaviour or an error by ifort?

...

Based on what I understand, your use of ASSOCIATE construct is correct and it is a bug/defect in the compiler.

[jimdempseyatthecove]

As a work around

 subroutine s(a)
  type(t2), intent(in) :: a
  type(t1), pointer :: at1
  at1 => a%p

   ! ...
   call at1%set_x()
   ! ...
 end subroutine s

Jim Dempsey

[Kevin_D_Intel]

The current Beta compiler also issues the same error. I reported it to Development (see internal tracking id below) and will keep you updated on a fix.

(Internal tracking id: DPD200357703)
(Resolution Update on 12/18/2014): This defect is fixed in the Intel® Parallel Studio XE 2015 Update 1 release (2015.0.133 - Linux)

[MR]

OK, thank you.

Marco

[Kevin_D_Intel]

This defect is fixed in the Intel® Parallel Studio XE 2015 Update 1 release (Version 15.0.1.133 Build 20141023 - Linux) now available from our Intel® Registration Center