Complier 14.0 error in pointer

[Zhanghong_T_]

Dear all,

I have the following code which works under Complier 13.1 or older version:

function getpoint(address)result(out)
implicit none
integer*8::address
type(point),target::out0
type(point),pointer::out
pointer(address,out0)
out=>out0
end function

where 'address' is assign in some other place by

address=loc(currpoint)

and currpoint is defined as

type(point),pointer::currpoint

However, when the code are compiled by compiler 14.0 (Package ID: w_fcompxe_2013_sp1.0.103), the result is wrong.

Is

pointer(address,out0)

still supported by compiler 14.0? if not, how to modify the above function to let the pointer be recovered from the address correctly?

Thanks,

Zhanghong Tang

[Zhanghong_T_]

Dear all,

I have attached the test code. Could anyone help me to take a look at it?

Thanks,

Zhanghong Tang

[Steven_L_Intel1]

The syntax is still supported, but you are doing something very strange with it. I will have to examine this in more detail. I suggest that you study the procedure C_F_POINTER in standard intrinsic modiule ISO_C_BINDING. It is a safer way to do what you have here.

[IanH]

This variant of your function has the benefit of being standard conforming and portable.  It works with the current release.

[fortran]function getpoint(address) result(out)
  use, intrinsic :: iso_c_binding, only: c_intptr_t, c_f_pointer, c_null_ptr
  integer(c_intptr_t), intent(in) :: address
  type(point), pointer :: out
  call c_f_pointer(transfer(address, c_null_ptr), out)
end function getpoint
[/fortran]

[Zhanghong_T_]

Dear Steve and IanH,

Thank you very much. The problem solved after updated the function as IanH provided.

Thanks,

Zhanghong Tang

[Andrew_Smith]

Try this instead:

 [fortran]function getpoint(address)result(out)

implicit none

integer*8::address

type(point),target::out0

type(point),pointer::out

pointer(i,out0)

i = address

out=>out0

end function[/fortran]

[Zhanghong_T_]

Hi Andrew,

Thank you very much for your kindly reply. I just tested the function you provided, it still can't get a correct result.

Thanks,

Zhanghong Tang

[Steven_L_Intel1]

Ok - I see what is going wrong. When you write out=>out0, the compiler should be "dereferencing" the address in the integer pointer. It isn't doing that, it's having out point to "address" rather what it points to. This is a bug and I will report it to the developers, though it sounds oddly familiar to me.... This bug also affect's Andrew's suggested alternative.  In any event, Ian's suggested alternative is vastly preferable and is what I recommend you use.

[Steven_L_Intel1]

Yes, this was indeed familiar. The bug was reported late in the beta of 14.0 and is fixed for update 1, planned for October. For reference, the issue ID is DPD200342622.

[Zhanghong_T_]

Dear Steve,

Thank you and you team very much for your so quick response.

Thanks,

Zhanghong Tang

[Zhanghong_T_]

Dear Steve,

I got to know that a new version of Intel Fortran compiler have been updated. Is the bug fixed?

On the other hand, when modify pointer to 'c_f_pointer' function, I have to define 'address' as 'integer(c_intptr_t)', however, the data 'address' is got from the function LOC, which return 'integer' in 32 bit program and 'integer*8' in 64 bit program. Should I replace the code

addres=LOC(currpoint)

to any other code, how to replace the code?

Thanks,

Zhanghong Tang

[Steven_L_Intel1]

Update 1 is out now, and the problem you reported is fixed there.

The reason for using c_intptr_t is that it is always the correct kind for the platform you're using. It's 4 for 32-bit and 8 for 64-bit.

[Zhanghong_T_]

Dear Steve,

Thank you very much for your kindly reply. So you mean that I can write like this?

integer(c_intptr_t)::address
...
addres=LOC(currpoint)
...
currpoint=>getpoint(address)

Thanks,

Zhanghong Tang

[Steven_L_Intel1]

You can write that and it will work, though it ends up seting currpoint to point to whatever it pointed to before. 

[Zhanghong_T_]

Dear Steve,

Just now I checked the fixed list from here:
http://software.intel.com/en-us/articles/intel-composer-xe-2013-compilers-sp1-fixes-list

I didn't find the issue ID DPD200342622, what did I miss?

Thanks,

Zhanghong Tang

[Steven_L_Intel1]

I don't know why it isn't listed, but it is fixed.

[plain]
C:\Projects>ifort mytest.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.103 Build 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 11.00.60315.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mytest.exe
-subsystem:console
mytest.obj

C:\Projects>mytest.exe
      908832  2.650234023756420E-314  0.000000000000000E+000
  4.322244370825894E-318

C:\Projects>ifort mytest.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.1.139 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:mytest.exe
-subsystem:console
mytest.obj

C:\Projects>mytest.exe
           1   1.00000000000000        2.00000000000000
   3.00000000000000

[/plain]

[Zhanghong_T_]

Dear Steve,

Thank you very much for your test. I'll update to the latest compiler latter.

Thanks,

Zhanghong Tang