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 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
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.

Retired 12/31/2016

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.

Retired 12/31/2016

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.

Retired 12/31/2016

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

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today