- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the answer and reporting the problem, Steve.
Chih-Chieh
Chih-Chieh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Any hope that a fix will be in ifort 13.0?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe that the fix for this problem will be in Update 1, due later this month. If not, then Update 2.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page