BUG in EOSHIFT function

Alex_S_5 · ‎04-05-2011

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

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

#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.

Steven_L_Intel1 · ‎04-05-2011

Thanks for your inquiry.

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.

Alex_S_5 · ‎04-05-2011

Thanks for the prompt reply, Steve.

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

mecej4 · ‎04-05-2011

Here is a workaround: add an array containing zeros, of the correct shape and type, to the expression on the right.

[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]

Steven_L_Intel1 · ‎04-05-2011

Of course, we do have a large test suite and add regression tests for every bug we fix. But I can tell you from my 33 years in the Fortran business, it is impossible to test every possible feature combination that people might try. I have seen bugs that were 25 years old show up for the first time. EOSHIFT is not a particularly common intrinsic, though I know we've had some use of it. Because it showed up in some benchmarks, we made an attempt to inline it and it's possible that this contributed to the problem you found.

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.

Alex_S_5 · ‎04-05-2011

mecej4,
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

Steven_L_Intel1 · ‎06-10-2011

This problem has been fixed in our sources. It should appear in a future update.