Optimization bug?

Optimization bug?

Please find below a very simple program that produces, on our computer,two dinstinct results depending on the optimization level. /03 and /02 are wrong while /Od and /O1 are fine. Any comment?

c compiler XE and XE
c ----------------------------------------
c with /O2 or /O3 gives : h(1,1) = 3.24890623206407
c with /Od or /O1 gives : h(1,1) = 59.7963890462363

program Test1

dimension h(100,50)

data h/5000*0./


do istep=1,30000
do i=1,ni
do k=1,nk

q1 = 0.
q2 = 1.
q3 = 0.
q4 = 0.

if(k.ne.1) q1 = h(i,k-1)-h(i,k)
if(k.ne.nk) q2 = h(i,k+1)-h(i,k)
if(i.ne.1) q3 = h(i-1,k)-h(i,k)
if(i.ne.ni) q4 = h(i+1,k)-h(i,k)

h(i,k) = h(i,k) + 0.1*(q1+q2+q3+q4)


h(ni,nk) = 0.


write(6,*) 'h(1,1) =', h(1,1)


8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I guess you may have set /real-size:64 (or one of its synonyms). I'm as surprised as you at this effect.

Specify your reals and do not rely on defaults.
I would use
REAL*8 H(100.50), Q1,Q2,Q3,Q4

DATA H/5000*0.0D+00/

and then see what happens...

If you spell it correctly (0.1d0), this should achieve the same result as /real-size:64. If not, that gives another flavor to the bug. I agree that for an algorithm which is so dependent on double precision, making it visible in the source code would be preferable.
If you look at the assembly code generated, you will see that -O2 causes the compiler to consolidate a full copy of everything in the loop inside each of the IF blocks, possibly in an effort to prepare for a peeling optimization which would remove the conditionals from the loop. In itself, this ought not to be disastrous, but it raises the point that the source code might be optimized in that direction.

We are planning on including a fix for this issue in a future release. I will update this thread when it is available.


I can reproduce the problem in 12.1 but not in our latest development version. Nevertheless, I have escalated this as issue DPD200178145 to verify that it was a bug that was deliberately fixed, and not just masked by other changes.

Steve - Intel Developer Support

I am told that the fix for this will be in Update 9, scheduled for February.

Steve - Intel Developer Support

Many thanks to all of you. We look forward Update 9.

Michel Ferry

Leave a Comment

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