- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
11 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> 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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see.
Thanks.
Akiko MATSUMOTO
Thanks.
Akiko MATSUMOTO
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Intel people,
Could you tell me you have any uodate?
Tanks,
Akiko MATSUMOTO
Could you tell me you have any uodate?
Tanks,
Akiko MATSUMOTO
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page