Pointer bounds remapping problem

Pointer bounds remapping problem

Portrait de chen146
chen146
ven, 18/05/2012 - 02:34

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.

RSS Haut
8 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Steve Lionel (Intel)
Steve Lionel (Intel)
ven, 18/05/2012 - 08:24
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
Haut
Portrait de chen146
chen146
sam, 19/05/2012 - 04:00

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

Chih-Chieh

Haut
Portrait de jimdempseyatthecove
jimdempseyatthecove
sam, 19/05/2012 - 05:07

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

Blog: The Parallel Void

www.quickthreadprogramming.com
Haut
Portrait de styc
styc
dim, 29/07/2012 - 21:23

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?

Haut
Portrait de Steve Lionel (Intel)
Steve Lionel (Intel)
lun, 30/07/2012 - 07:05

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
Haut
Portrait de Steve Lionel (Intel)
Steve Lionel (Intel)
ven, 24/08/2012 - 12:14

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
Haut
Portrait de Steve Lionel (Intel)
Steve Lionel (Intel)
lun, 01/10/2012 - 12:06

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

Steve
Haut

Connectez-vous pour laisser un commentaire.