Complier 14.0 error in pointer

Complier 14.0 error in pointer

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

publicaciones de 17 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Dear all,

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

Thanks,

Zhanghong Tang

Adjuntos: 

AdjuntoTamaño
Descargar mytest.f90863 bytes
Imagen de Steve Lionel (Intel)

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.

Steve

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

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

Dear Steve and IanH,

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

Thanks,

Zhanghong Tang

Imagen de Andrew Smith

Try this instead:

 

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

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

Imagen de Steve Lionel (Intel)

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.

Steve
Imagen de Steve Lionel (Intel)

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.

Steve

Dear Steve,

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

Thanks,

Zhanghong Tang

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

Imagen de Steve Lionel (Intel)

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.

Steve

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

Imagen de Steve Lionel (Intel)

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

Steve

Dear Steve,

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

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

Thanks,

Zhanghong Tang

Imagen de Steve Lionel (Intel)

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

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

Steve

Dear Steve,

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

Thanks,

Zhanghong Tang

Inicie sesión para dejar un comentario.