Pointer bounds remapping problem

Pointer bounds remapping problem


This is a simple program using pointer bounds remapping:


program main
implicit none

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



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.

8 帖子 / 0 全新
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.


Thank you for the answer and reporting the problem, 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(:,:)
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


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?

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.


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.


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