Problem with pointers to derived type components in compiler version 12.0

[otte]

Hi,

I am having problems with pointers to components of derived types with Intel Fortran Composer XE 2011. The problem occurs with optimization level O3 in versions12.0.0.084 and12.0.1.107 on linux and with a trial ofVersion 12.0 Build 20101110 on Mac OSX, all with the 64-bit version of the compiler (I have not checked the behavior with the 32-bit compiler versions). The original code is long, so I'll try to give a summary here of my problem with code examples.

A derived type called scalar_table is defined in a module:

[fortran]type scalar_table
   real, pointer :: var_p(:,:)
   real, pointer :: var_t(:,:)
   character (len=32) :: name  
end type
type(scalar_table), allocatable :: scalar_tab(:)
[/fortran]

Later in the main program, we allocate scalar_tab:

[fortran]allocate (scalar_tab(maxsclr))[/fortran]

Scalar_tab just helps us to keep track of all of the variables on our program. For all of the prognostic variables in our program, we call a subroutine that sets the pointers of scalar_tab:

[bash]subroutine vtables_scalar(varp,vart,name,nv)
real, target :: varp(:,:)
real, target :: vart(:,:)
character(32), intent(in) :: name
integer, intent(in) :: nv
nv = nv + 1
scalar_tab(nv)%name = cname
scalar_tab(nv)%var_p => varp
scalar_tab(nv)%var_t => vart
end subroutine vtables_scalar[/bash]

That part works nicely, but when we want to back-out the components of scalar_tab into pointers, the pointers are not referencing the proper arrays:

[fortran]subroutine scalar_transport()
use var_tables, only: scalar_tab, nv
real, pointer :: scp(:,:)
real, pointer :: sct(:,:)

! Loop over scalars

do n = 1,nv

  ! Point SCP and SCT to scalar arrays
  scp => scalar_tab(n)%var_p
  sct => scalar_tab(n)%var_t

  write(*,*) "  array_P   ", "  array_T   ", "pointer_to_P ", "pointer_to_T "

  write(*,'(4G12.4)') scalar_tab(n)%var_p(1,2), scalar_tab(n)%var_t(1,2), &
                      scp(1,2), sct(1,2)
  ....[/fortran]

I added the write statements to show where the code is going wrong. When I compile the code at level O3, these write statements produce:

[bash]   array_P     array_T   pointer_to_P pointer_to_T 
   0.7043E-02   0.000    0.7043E-02   0.7043E-02[/bash]

As you can see, pointer sct is not pointing to the correct original array. At level O2 (and with the previous compiler versions) I get the correct result:

[fortran]  array_P     array_T   pointer_to_P pointer_to_T 
  0.7043E-02   0.000    0.7043E-02   0.000    
[/fortran]

and sct points to the correct array values.As a workaround, I CAN get the proper results at level O3 if I change the pointer association statements above to explicitly include the array subscripts:

[fortran]scp => scalar_tab(n)%var_p(:,:)
sct => scalar_tab(n)%var_t(:,:) [/fortran]

It looks like that without the explicit array subscripts, sct is being pointed to the first member of the derived type rather then the derived type component.If necessary, I can try to simplify the original code into a small example that shows this problem.

Thanks for your help,

Martin

[Steven_L_Intel1]

A simple example would be appreciated - thanks.

[otte]

Hi,

I finally had enough time to get a smaller example, which I am attaching here in the file pointers.f90. At optimization level O3, the pointer sct in subroutine pointers_broken is not associated with the proper target array. I don't think I'm doing something wrong in the code, so thanks for looking over this code.

Martin

[Timmo1]

Hi,

i have a similar problem with types and pointers. i have written a small example in type.f90. Type B is working with a additional pointer p, which is unnecessary to my mind. I want use the shorter version module A.

We want to change only the value of x in the Type t_node, not the complete adress "elements(1)%nodes(1)%x".

I use intel visual compiler for linux 11.1.064 here is the file: type.f90

I'am very unexperienced in the field of pointers, but i hope someone can help me in this forum.


Cheers

Timmo

[david_car]

Hi Martin,

I just ran your example and reproduced it on my Linux box. Looks like a bug. I didn't a little fooling around and got it to work with -O3 by using the slice notation when pointing to thescalar_tab(n)%var_p andscalar_tab(n)%var_t pointers. I've attached the file. Maybe this will give more clues to the ifort developers.

[Steven_L_Intel1]

Escalated as issue DPD200165253. I could reproduce this on IA-32 as well.

[Steven_L_Intel1]

This has been fixed in our sources. I expect the fix to appear in a future update (perhaps update 4.)

[jimdempseyatthecove]

Martin,

I do not have a working test example and platform to reproduce your problem. In looking at your subroutine vtables_scalar you have a programming error that may not be reported by the compiler and which is the root cause for erronous code.

Jim Dempsey

[fortran]subroutine vtables_scalar(varp,vart,name,nv)
real, target :: varp(:,:)
real, target :: vart(:,:)
character(32), intent(in) :: name
integer, intent(in) :: nv
nv = nv + 1 ! **^** shouldn't nv be intent(inout)???
scalar_tab(nv)%name = cname
scalar_tab(nv)%var_p => varp
scalar_tab(nv)%var_t => vart
end subroutine vtables_scalar







[/fortran]

[Steven_L_Intel1]

Jim, the compiler definitely complains about that one:

t2.f90(6): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined. [NV]
nv = nv + 1 ! **^** shouldn't nv be intent(inout)???

[jimdempseyatthecove]

Okay,

Now then, Marten reported a compiler version that was slightly older that the one you are using, andif Martin's supplied code was the actual misbehaving code, including coding error, and if Martin was not receiving a compiler error message (my postulation), then it would be appropriate to follow the lead that the compiler error in failing to detect ack of INTENT(INOUT) could potentially be the same cause for the execution code error observed....

So... Martin, was the code you submitted in your original post using INTENT(IN) for variable NV?
I can only imagine that you use copy and paste of the symtomatic code in your original post.

Jim

[martinotte]

Hi,

Please see my full example (pointers.f90) in the second reply to this thread, which contains a full working program. In the first post, I was still floundering around trying to simplify my much larger code into a small example that demonstrates this problem. I am glad that this will be fixed in an upcoming update!

Martin

[Steven_L_Intel1]

It should be fixed in Update 4, which is available now.