- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following code shifts a portion of an integer array one position and assigns it to a portion of another array (I have not tried to simplify it further):
program test_intel_visual_fortran
integer(4) :: a(0:7)=(/0,1,2,3,4,5,6,7/)**2
integer(4) :: ar(0:7) = 0
ar(2:7-2) = eoshift(a(2:7-2),shift=1)
print*, "a ", a(2:7-2)
print*, "ar", ar(2:7-2)
end program test_intel_visual_fortran
When compiled and run on the LINUX with the latest available ifort v 12.x.x. compiler
#ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.0.084 Build 20101006
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
as well as with the (about 1.5 years old) ifort v 11.1.059
#ifort -O0 test_intel_visual_fortran.f90
#a.out
it produces an INCORRECT result:
a 4 9 16 25
ar25 0 0 0
Gfortran, Intel Linux ifort v 10.1.015, v 9.1.045, and Window Intel Visual Fortran 11.x.x
all produce the CORRECT ouput:
#ifort -V
Intel Fortran Compiler for applications running on Intel 64, Version 10.1 Build 20080312 Package ID: l_fc_p_10.1.015
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
#ifort -O0 test_intel_visual_fortran.f90
#a.out
a 4 9 16 25
ar 9 16 25 0
The 11.1.x and 12.x.x.x produce incorrect values for real(4)'s and integer(8)'s sometimes misshifting the array
by 1 and sometimes by 2 extra elements.
Please confirm and, if true, that is really disturbing how that could have happened in the first place and
may indicate a systemic problem with the intel compiler quality assurance process, that it let through
a BUG in an intrinsic functon and have not intercepted it since at least june 2009!
It is indeed hard to belive.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your test program doesn't really demonstrate what you claim - that there is a bug in EOSHIFT. What I find, when I enhance the program, is that EOSHIFT is returning the correct results in version 12, but the assignment of the result to an array slice ignores the specified lower bound for the destination. So instead of assigning to elements 2:5, it assigns to 0:3. This is not a general problem, as if you assign another array of the correct shape to such a slice it works. I don't yet know if this issue is limited to EOSHIFT or if it is generic to functions returning array results.
In any case, it is an unusual combination of things that leads to the incorrect results, which helps explain why we did not find it earlier (nor had it been reported to us earlier.) I have escalated this as issue DPD200168025 and will update this thread as we make progress on it. Thanks for bringing it to our attention.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CSHIFT workedfine soIassociated thebugwith the EOSHIFTfunction
Idisagree withyour statement that thecombination is "unusual", as
the intrinsic array-routines and array slicesare used just everywhere in fortran 90/95.
And I do not see a plausible explanation as to why this bug had not beendiscovered
in almost 2 years. Maybe, everybody who runs theintel compiler on linux clusters
has been (like us) putting off upgrading to newer versions, or is using mostly f77 style programming, etc.
On the other note, Iremembera somewhatsimilar problem of passing array slices as arguments with an
intel fortran on Itanium about 5 yearsagoor so. That time Ithought, it was because the platform was
relatively new and not allbugs had been worked out (the bug was fixed in a matter of days).
So, it would really be nice if the above code (or a similar one) becomes a
part ofthe intel fortran release"quality assurance suite" (you guys do
have anelaboratedquality assurance procedure with gazillion of test routins, don't you?)
which would guarranty that at least this exact bug will NEVER appear inANY of the next releases.
Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[fortran]program test_intel_visual_fortran integer(4) :: a(0:7)=(/0,1,2,3,4,5,6,7/)**2, ii(4)=0 integer(4) :: ar(0:7) = 0 ar(2:7-2) = eoshift(a(2:7-2),shift=1) + ii print*, "a ", a(2:7-2) print*, "ar", ar(2:7-2) end program test_intel_visual_fortran [/fortran]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Once we fix it, it should stay fixed because we will test for it. But it's entirely possible, and I have seen this, that a slightly different program, one that you'd think was equivalent, excercised a new combination of code paths and triggered a seemingly identical bug. That's just the way it is with compilers.
As for your comment about people staying with old versions - that's definitely not the norm. What I think is unusual about your program is that you assign to an array section with a lower bound not at the beginning of the array and you are using EOSHIFT - both of those are not common and the combination is even less so. That doesn't make it any less of a bug and we will fix it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are many workarounds.
Here is another one that I prefer as it does not use the intrinsic and I hope
the array-slice syntax is interpreted correcly by any fortran 90/95 compiler
ar(2:(7-2-1)) = a(2+1:(7-2-1)+1); ar(7-2)=0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page