ifort bug with pointer and intent(in)

[muthphysik_uni-kl_de]

ifort_intent_pointer_error.F90:[fortran]program ifort_intent_pointer_error implicit none type intp integer, pointer :: p end type integer, target :: i = 1 type(intp) :: p p%p => i print *, p%p call settwo(p) print *, p%p contains subroutine settwo(p) type(intp), intent(in) :: p p%p = 2 end subroutine end program[/fortran] gfortran accepts this:$ gfortran-4.4 -Wall -o ifort_intent_pointer_error.gfortran-4.4 ifort_intent_pointer_error.F90$ ./ifort_intent_pointer_error.gfortran-4.4 1 2however ifort complains:$ /opt/intel/bin/ifort -warn all -o ifort_intent_pointer_error.ifort-12.0.5 ifort_intent_pointer_error.F90ifort_intent_pointer_error.F90(22): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.

p%p = 2--^compilation aborted for ifort_intent_pointer_error.F90 (code 1)$ /opt/intel/bin/ifort -VIntel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0 Build 20110719Copyright (C) 1985-2011 Intel Corporation. All rights reserved.In my opinion ifort should not complain, because only the object containing the pointer may not be modified due to intent(in), but it's target may.

[Kevin_D_Intel]

Thank you for the nice concise test case. It appears ifort becomes confused with naming the variable of type INTP the same as the pointer within the derived type. You may work around using either INOUT or using unique names for the variable of type INTP and the associated dummy argument, or the pointer in the derived type (and references to it).

I reported this to Development and will update this thread regarding a fix as I learn it.

(Internal tracking id: DPD200172333)

(Resolution Update on 10/14/2012): This defect is fixed in the Intel® Fortran Composer XE 2013 Initial Release (2013.0.0.079 - Linux)

[muthphysik_uni-kl_de]

Thanks for your immediate reply. Indeed renaming helps in my simple test case: The following version compiles fine:

-----

[fortran]program ifort_intent_pointer_error

implicit none

type intp
  integer, pointer :: p
end type

integer, target :: i = 1
type(intp) :: t

t%p => i

print *, t%p
call settwo(t)
print *, t%p

contains

subroutine settwo(u)
  type(intp), intent(in) :: u
  u%p = 2
end subroutine

end program[/fortran]

-----

[muthphysik_uni-kl_de]

The following example is closer to my actual programm and does not work:

[fortran]program ifort_intent_pointer_errorV2

implicit none

type intp
  integer, pointer :: p
end type

type intp_r1_p
  type(intp), dimension(:), pointer :: p
end type

integer, target :: i = 1
type(intp_r1_p) :: t

allocate(t%p(1))

t%p(1)%p => i

if (associated(t%p(1)%p)) then
  print *, t%p(1)%p
else
  print *, 'not associated'
end if
call settwo(t)
if (associated(t%p(1)%p)) then
  print *, t%p(1)%p
else
  print *, 'not associated'
end if

print *, 'i =', i

contains

subroutine settwo(u)
  type(intp_r1_p), intent(in) :: u
  u%p(1)%p = 2
  nullify(u%p(1)%p)
end subroutine

end program[/fortran]

$ /opt/intel/bin/ifort -warn all -o ifort_intent_pointer_errorV2.ifort-12.0.5 ifort_intent_pointer_errorV2.F90

ifort_intent_pointer_errorV2.F90(39): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.

nullify(u%p(1)%p)

compilation aborted for ifort_intent_pointer_errorV2.F90 (code 1)

Note thatu%p(1)%p = 2 is accepted, but only the nullify is not.

Again, gfortran compiles this. Program output is

$ ./ifort_intent_pointer_errorV2.gfortran-4.4

1

not associated

i = 2

[Kevin_D_Intel]

Thank you for the updates. I added the example that more closely resembles your actual program to the internal tracking report to ensure both variants are verified as fixed.

Only the workaround of using INOUT avoids this error for this latest example and I expect perhaps for your actual program also.

[Kevin_D_Intel]

Both cases cited in this thread that failed to compile have been fixed in our current Intel® Fortran Composer XE 2013 Initial Release (2013.0.0.079 - Linux).