Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29280 Discussions

character init/ not working if statement

hdankowski
Beginner
563 Views
Hi,

we just tested the new Intel Compiler 12 with our large Fortran project. We encountered a problem with the following routine:

subroutine buftex_calc(iomode,ioerr)

implicit none
include "buftex_calc.h"

integer :: ioerr,iomode
intent (in) iomode
intent (out) ioerr

character(256) :: fname
character(8) :: fstat
integer :: itmp

ioerr = -2
if (iomode.eq.0.or.iomode.eq.1) then
fstat = 'OLD'
elseif (iomode.eq.2) then
fstat = 'UNKNOWN'
else
goto 9009 ! error
endif
call bugenv0(fname,'BUFTEX_CALC_PRG'//char(0))
if (fname(:1).eq.char(0).or.fname(:1).eq.' ') then
fname = 'buftex_calc.prg'
endif
ioerr = -1
call e4open_init()
call e4open_setstatus(fstat)
call e4open_setfilename(fname)
call e4open_execerr(1,*9009)
....
end subroutine


The problem occurs with the "fstat" variable. The variable "iomode" does actually have the value one but the "fstat" variable is never set!

If one inits fstat at the beginning, the code works fine. The additional problem is, that the error cannot be reproduced with a dummy program..

And: This only happens in the optimized version!
Any idea? Is the first if condition thought to be safe to be removed?

This worked for over 20 years with any compiler (also with the last version of the ifort..).

Regards,
Hendrik
0 Kudos
1 Reply
mecej4
Honored Contributor III
563 Views
In a situation where the compiler is doing something for which there is no justification or explanation, it is essential to have a "reproducer", i.e., a complete program that is as short as possible but displays the problematic behavior in the compiled code when built with the reported compiler options. Constructing such a reproducer can be time-consuming, but the effort is worthwhile. Given such a reproducer, Intel has been consistently responsive in fixing the compiler.

A simple, if time-consuming way, is to start with your full code, and lop off pieces one at a time. If a change makes the bug disappear, back up to the previous version and look for something else to lop off. I know this sounds unappetizing, but I once started with 70,000 lines of code and had a 70 line reproducer after many hours of work. The responsible optimizer bug was fixed in IFort 11.1.7.

And there exists a small chance of your description of the symptoms having us bark up the wrong tree.
0 Kudos
Reply