Allocate pointer in subroutine cause access violation

[Intel_C_19]

I'm nearly new to fortran, sometimes think in the c++ style way, so this simple code confused me a lot.

integer, pointer :: x
integer, target :: l
l=0
x=>l
call aaaa(x)
write(*,*)associated(x),x
deallocate(x)
end
subroutine aaaa(xx)
integer, pointer ::xx, y
allocate(y)
y=1
xx=>y
end subroutine aaaa

The above is the codecauses access violation.

Firstly, as you can see I declare a integer target 'l' in the main procedure. if I don't do this , just let x to be null and then call aaaa, whatever i do with the pointer x in aaaa(write it, check the association state) a "Program Exception - access violation" will be throw out when i execute the program.

Secondly, the current code will write "T" and an random number after it, then throw out an"Program Exception - access violation". It looks like the allocated y has already been deallocted when returns aaaa, and the association state seems to be wrong.

of cause, this program is very badly coded. It is my intention to test if i can allocate a pointer in one subroutine and use the allocated pointer in another subroutine, may deallocate it in a third subroutine, I'd wish the pointer can be aderived type. However, i can't even get it run with integer....;(

i'd appreciate anyone tell me the reason.

ps: ifort is Version 12.0.2.154 Build 20110112

[Steven_L_Intel1]

Because the subroutine has a pointer argument, an explicit interface is required. The compiler would tell you this if you built from Visual Studio, or add the /warn:interface option on the command line. Without that, you will get all sorts of weird behavior as the caller doesn't know that the subroutine wants a pointer passed, so it passes the target of the pointer, thevariable I.

The easy way to fix this is to make aaa a contained procedure, like so:

[fortran]integer, pointer :: x
integer, target :: l
l=0
x=>l
call aaaa(x)
write(*,*)associated(x),x
deallocate(x)
contains
subroutine aaaa(xx)
integer, pointer ::xx, y
allocate(y)
y=1
xx=>y
end subroutine aaaa
end[/fortran]

[Intel_C_19]

Thank you so much , Steve.

BTW, just now, i find another problem, if there is a "select type" in openmp parallel region, the compiler can't compile and says

catastrophic error: **Internal compiler error: internal abort** Pleasereport this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of thiserror.

[jimdempseyatthecove]

In your "program" section add an INTERFACE to aaaa

[fortran]integer, pointer :: x
integer, target :: l
interface
  subroutine aaaa(xx)
    integer, pointer ::xx
  end subroutine aaaa
end interface
l=0 
x=>l
call aaaa(x)
write(*,*)associated(x),x
deallocate(x)
end
subroutine aaaa(xx)
  integer, pointer ::xx, y
  allocate(y)
  y=1
  xx=>y
end subroutine aaaa[/fortran]

Jim Dempsey

[jimdempseyatthecove]

This works with

w_fcompxe_2011.4.196

both x32 and x64

[Steven_L_Intel1]

Please provide a short example demonstrating the internal compiler error.

[Intel_C_19]

!$omp parallel

do

if (ASSOCIATED(tp)==.true.) then
write(*,*) tp%x(1),tp%x(2),tp%x(3),'xx'
!SELECT type(tp)
!type is (mdslist)
!ttp=>tp%typ(listleveln,1)%p
!end select
tp=>ttp
else
exit
end if
end do

!$omp end parallel

this is part of the code, only when i comment the select type part, the compiler can run correctly.

initially, 'tp' is the head of skip list which has a "class (listele) pointer" type. 'ttp' is the same kind as 'tp'. the list defined as following. (one thing i forgot to paste here, tp and ttp are declared as "omp private")

TYPE :: listele
INTEGER, allocatable, dimension ( : ) :: x
INTEGER :: d
CONTAINS
FINAL :: Delistele
END TYPE listele

TYPE :: p2listele !to realize a point array
CLASS (listele), POINTER :: p
END TYPE p2listele

TYPE, EXTENDS(listele) :: mdslist !the final list
TYPE (p2listele), allocatable, dimension ( :, : ) :: typ
CONTAINS
FINAL :: Demdslist
END TYPE mdslist

i also wish to know when 'Parameterized derived types' will be add to intel fortran, thanks.

[Steven_L_Intel1]

We determined that a fix we made for ASSOCIATE in a parallel region also took care of SELECT TYPE. This fix will appear in a future update.

We cannot say at this time when parameterized derived types will be implemented.