topic When I put -O2 on my fortran program, the answer is wrong. in Intel® Fortran Compiler

When I put -O2 on my fortran program, the answer is wrong.

amat000 — Wed, 15 Feb 2012 11:00:38 GMT

Hello,

I have attached 2 source files.
The correct answer is "N=2", but when I specify -O2 the answer is "N=1".
Could you check this behavior?
Compiler version : 12.1.1.256 Build 20111011
processor : X5690

best regards,
Akiko MATSUMOTO

$ cat prog.f
program PROG
character*12 DDNAME,FILENM
common /PP/DDNAME(3),IFLSW,FILENM
integer N
DDNAME(2) = 'ABCDEF'
FILENM = 'ABCDEF'
IFLSW=1
CALL CHECK(N)
write(*,*) "N ",N
stop
end

$ check.f
SUBROUTINE CHECK(N)
CHARACTER*12 DDNAME,FILENM
COMMON /PP/ DDNAME(3),IFLSW,FILENM
INTEGER N
N = 1
IF(IFLSW.EQ.0) RETURN
DO 10 I = 2 , 3
N = I
IF(FILENM(1:8).EQ.DDNAME(I)(1:8)) RETURN
10 CONTINUE
STOP
END

$ ifort -O0 *.f
$ ./a.out
N 2

$ ifort *.f
$ ./a.out
N 1

$ ifort -ipo *.f
$ ./a.out
N 2

When I put -O2 on my fortran program, the answer is wrong.

TimP — Wed, 15 Feb 2012 12:26:36 GMT

I don't run into this problem, using ifort 12.1.2 Intel64. Note that when you set up COMMON with implied misalignment by mixing storage units, the optimizer is likely to run into difficulty. Your source code looks like Fortran 77, except that mixing CHARACTER with other storage units in COMMON wasn't permitted in f77.
Also, leaving part of an array uninitialized is dangerous even though you may have initialized the bits which you access explicitly. Did you display the strings which you are accessing to see whether they were correctly blank filled?

When I put -O2 on my fortran program, the answer is wrong.

amat000 — Thu, 16 Feb 2012 04:18:13 GMT

TimP-san,

Thank you for your comment.
I understand my source code had mistakes, so I correct that.
I am afraid the wrong answer is still printed.

Anyway, is 12.1.2 Intel64 released? I would like to use that compiler.

best regards,
Akiko MATSUMOTO

New source codes
prog.f
program PROG
character*8 DDNAME,FILENM
common /P1/DDNAME(4),FILENM
common /P2/IFLSW
integer N
do i=1,4
DDNAME(i)= ' '
enddo
DDNAME(2) = 'ABCDEF'
FILENM = 'ABCDEF'
IFLSW=1
CALL CHECK(N)
write(*,*) "N ",N
stop
end

check.f
SUBROUTINE CHECK(N)
CHARACTER*8 DDNAME,FILENM
COMMON /P1/ DDNAME(4),FILENM
COMMON /P2/ IFLSW
INTEGER N
N = 1
IF(IFLSW.EQ.0) RETURN
DO 10 I = 2 , 4
N = I
IF(FILENM(1:8).EQ.DDNAME(I)(1:8)) RETURN
10 CONTINUE
STOP
END

When I put -O2 on my fortran program, the answer is wrong.

mecej4 — Thu, 16 Feb 2012 04:31:35 GMT

Compilers version 12.1.2 ("Update 8") were released in December. I do not see the reported errors with the Windows versions of this release.

When I put -O2 on my fortran program, the answer is wrong.

amat000 — Thu, 16 Feb 2012 10:20:01 GMT

TimP-san,

I am afraid Compiler 12.1.2.273 Linux version doesn't solve this issue.

$ ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.2.273 Build 20111128
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.

$ ifort prog.f check.f
$ ./a.out
N 1
$ ifort -O0 prog.f check.f
$ ./a.out
N 2

What should I do next? Any comments will be appreciated.

best regards,
Akiko MATSUMOTO

When I put -O2 on my fortran program, the answer is wrong.

mecej4 — Thu, 16 Feb 2012 10:56:34 GMT

I can duplicate the error in the revised code with the 64-bit version of the 12.1.2 compiler on Linux. The 32-bit compiler, same version, is not affected.

Furthermore, the error can be localized to an optimizer bug when compiling the subroutine in file check.f, at optimization level 2 or higher.

Curiously, at -O1 the produced code uses only the integer registers, whereas at -O2 the XMM registers are used.

Until the bug is fixed, see if you can get by with compiling just check.f with -O1 and the rest of the code at your chosen optimization level.

When I put -O2 on my fortran program, the answer is wrong.

Georg_Z_Intel — Thu, 16 Feb 2012 14:27:00 GMT

Hello,

I can reproduce your problem and high likely looks like a problem in our vectorizer (enabled with option "-O2"). As a workaround I can offer you to use option "-no-vec" (for selected compilation units) which turns off the vectorizer.
I'll create a defect ticket (edit: DPD200274990) to get this fixed and let you know when done.

Best regards,

Georg Zitzlsberger

When I put -O2 on my fortran program, the answer is wrong.

amat000 — Fri, 17 Feb 2012 09:04:03 GMT

mecej4-san and Zitzlsberger-san,

Thank you for your reply.
Until this issue is fixed, I put -O1 or -no-vec flag on check.f

Zitzlsberger-san, thank you for creating defect ticket.
( It is necessary to ask engineer fixing compiler issue, isn't it?)
I will wait for your next information.

best regards,
Akiko MATSUMOTO

When I put -O2 on my fortran program, the answer is wrong.

mecej4 — Fri, 17 Feb 2012 11:52:31 GMT

> It is necessary to ask engineer fixing compiler issue, isn't it?

No; if you click on the small box "Subscribed to this Thread" at the top of this thread, you will be notified by E-mail when the bug is acted upon.

An Intel person will update this thread, as well.

When I put -O2 on my fortran program, the answer is wrong.

amat000 — Fri, 17 Feb 2012 12:24:14 GMT

I see.
Thanks.

Akiko MATSUMOTO

When I put -O2 on my fortran program, the answer is wrong.

amat000 — Fri, 20 Apr 2012 06:27:17 GMT

Hello Intel people,

Could you tell me you have any uodate?

Tanks,
Akiko MATSUMOTO

When I put -O2 on my fortran program, the answer is wrong.

Georg_Z_Intel — Wed, 13 Jun 2012 09:06:54 GMT

Matsumoto-san,

I'm sorry to answer that late. I was waiting for the official verification whether DPD200274990 is fixed. Unfortunately there was a problem with our internal tracking system this time and I was not made aware that a fix has already been committed.

However, I'm happy to tell you that Intel Composer XE 2011 Update 10 should work for you now.

Thank you for your patience & best regards,

Georg Zitzlsberger