Pointer bounds remapping problem

Pointer bounds remapping problem

Imagen de chen146

Hello,

This is a simple program using pointer bounds remapping:

---------------------------------

program main
implicit none

real, target :: x2(4,2)
real, pointer :: a(:,:)

x2=0.0
x2(1,1)=1.0

a(1:2,1:2)=>x2(:,2)

write(*,*) x2(:,2)
write(*,*) a

end program

------------------------------

I compiled this by Intel Fortran Composer XE ( ifort version 12.1.3 ) on Ubuntu 10.04 and it gives me the following result:

0.0000000E+00 0.0000000E+00 0.0000000E+00 0.0000000E+00
1.000000 0.0000000E+00 0.0000000E+00 0.0000000E+00

which looks weired to me since I thought the 2nd row should be the same as the 1st row.

Am I doing something wrong or is this a bug? Thank you and I appreciate your help.

publicaciones de 8 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Steve Lionel (Intel)
Best Reply

This looks like a compiler bug to me. It surprises me as I know we did a lot of work on pointer remapping in the past year. I have escalated it as issue DPD200182165. Thanks for the small example.

Steve
Imagen de chen146

Thank you for the answer and reporting the problem, Steve.

Chih-Chieh

Imagen de jimdempseyatthecove

Steve,

FWIW I've seen the very same problem. This was in my code for a long time, but I only observed the error recently.

I used to have 1 based arrays, A(1:N). I needed to make a change to contain a cell before and after the array. So the array became A(0:N+1). Some integration code though needed to operate on A(1:N). Along the way the array slice is passed via a pointer "real, pointer :: p(:)" with p => A(1:N). However, p getting pointer to the 0'th element. The problem didn't introduce an observable error, I just happened to fall into observing the issue recently.

Also, related

In VS 2010 (Windows) if I have

real, pointer :: array(:,:)
...
allocate(array(3,0:N+1)
....
subroutine
real, automatic :: sv(3) ! or recursive wo/automatic
...
sv = array(:,I) ! copy the i'th vector (0-based index)

The proper value is copied, however, highlighting array(:,I), then Watch or Memory brought up the address of the 0'th index. IOW I suspect the ":" isn't parsed correctly by the debugger.

Sorry I do not have a simple reproducer. This is more of a "heads up" to the forum readers to take a look at their code (not what the source says, rather what the compiled code is doing).

Jim Dempsey

www.quickthreadprogramming.com
Imagen de styc

I ran into probably the same issue today with ifort 12.1.5 (-O0 optimization). The program did not crash with -check bounds. The numbers just silently went wrong. I did not find out the cause until I used LOC() to checked the addresses.

Any hope that a fix will be in ifort 13.0?

Imagen de Steve Lionel (Intel)

Sorry, this problem is not yet fixed. I have asked the developer to whom it is assigned for an update on status. I expect the fix will go in to an update to 13.0, but it won't make the initial release.

Steve
Imagen de Steve Lionel (Intel)

This has been fixed in our sources - it took a while because we decided to implement the new aspects of pointer assignment from F2008 while we were in that part of the compiler. At this point I don't know when the fix will appear, but as I get news I will update this thread.

Steve
Imagen de Steve Lionel (Intel)

I believe that the fix for this problem will be in Update 1, due later this month. If not, then Update 2.

Steve

Inicie sesión para dejar un comentario.