Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29274 Discussions

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

amat000
Débutant
1 520 Visites
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
0 Compliments
11 Réponses
TimP
Contributeur émérite III
1 520 Visites
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?
0 Compliments
amat000
Débutant
1 520 Visites
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

0 Compliments
mecej4
Contributeur émérite III
1 520 Visites
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.
0 Compliments
amat000
Débutant
1 520 Visites
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
0 Compliments
mecej4
Contributeur émérite III
1 520 Visites
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.
0 Compliments
Georg_Z_Intel
Employé
1 520 Visites
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
0 Compliments
amat000
Débutant
1 520 Visites
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
0 Compliments
mecej4
Contributeur émérite III
1 520 Visites
> 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.
0 Compliments
amat000
Débutant
1 519 Visites
I see.
Thanks.

Akiko MATSUMOTO
0 Compliments
amat000
Débutant
1 519 Visites
Hello Intel people,

Could you tell me you have any uodate?

Tanks,
Akiko MATSUMOTO
0 Compliments
Georg_Z_Intel
Employé
1 519 Visites
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
0 Compliments
Répondre