ifort: bug with option -save

[milsim]

option -save doesn't work well with arrays

ifort version: (ifort -V)

Intel Fortran Compiler Professional for applications running on IA-32,

Version 11.1 Build 20090827 Package ID: l_cprof_p_11.1.056

(ifort -what)

Intel Fortran 11.1-2582

See the following example with two simple fortran source files:

file #1: savetest.f

[fxfortran]c  main program: test option -save
      program savetest

      implicit none
      real sub_in(2)
      real sub_out(5)
      integer i

      do i=1,31
        sub_in(1)=real(i)
        sub_in(2)=real(mod(i,2))
        call sub_sub(sub_in,sub_out)
c output on screen
        if(i.lt.6 .or. i.gt.25) then
          print'(i3,'' iframe='',f4.0,'' delayh:'',2f6.2,'' ...''2f6.2)'
     &   ,i,sub_out
        endif
        if(i.eq.6 ) print'('' .....'')'
      enddo
      end

[/fxfortran]

file #2: sub_sub.f

[fxfortran]c shift values in array delayh every second call
      subroutine sub_sub(rinp,rout)
      implicit none
      integer dim
c  dim=13 works !!!
      parameter (dim=14)
      real rinp(*),rout(*),delayh(dim)
      integer iframe,i
#ifdef SAVE_DELAY
      save
#endif

c  first call: set default values in array delayh
      if(rinp(1).eq.1.0) then
         do i=1,dim
           delayh(i)=-0.01*i
         enddo
         iframe=0
      endif

      if (iframe .eq. 0) then
         iframe = 1
         do i = 1,dim-1
            delayh(i) = delayh(i+1)
         end do
         delayh(dim) = rinp(1)
      else
         iframe = 0
      end if

      rout(1)=real(iframe)
      rout(2)=delayh(1)
      rout(3)=delayh(2)
      rout(4)=delayh(dim-1)
      rout(5)=delayh(dim)
      end

[/fxfortran]

---------------------------------------------------------------------

Result when compiling and running WITH explicit save ("-DSAVE_DELAY"): OK

[bash]ifort -fpp -zero -save -CB -c savetest.f

ifort -fpp -zero -save -CB -DSAVE_DELAY -c sub_sub.f

ifort savetest.o sub_sub.o -o comp_test_1

comp_test_1

[/bash]

1 iframe= 1. delayh: -0.02 -0.03 ... -0.14 1.00
2 iframe= 0. delayh: -0.02 -0.03 ... -0.14 1.00
3 iframe= 1. delayh: -0.03 -0.04 ... 1.00 3.00
4 iframe= 0. delayh: -0.03 -0.04 ... 1.00 3.00
5 iframe= 1. delayh: -0.04 -0.05 ... 3.00 5.00
.....
26 iframe= 0. delayh: -0.14 1.00 ... 23.00 25.00
27 iframe= 1. delayh: 1.00 3.00 ... 25.00 27.00
28 iframe= 0. delayh: 1.00 3.00 ... 25.00 27.00
29 iframe= 1. delayh: 3.00 5.00 ... 27.00 29.00
30 iframe= 0. delayh: 3.00 5.00 ... 27.00 29.00
31 iframe= 1. delayh: 5.00 7.00 ... 29.00 31.00

---------------------------------------------------------------------

WRONG result when compiling and running w/o explicit save:

[bash]ifort -fpp -zero -save -CB -c savetest.f

ifort -fpp -zero -save -CB -c sub_sub.f

ifort savetest.o sub_sub.o -o comp_test

comp_test

[/bash]

1 iframe= 1. delayh: -0.02 -0.03 ... -0.14 1.00
2 iframe= 0. delayh: -0.02 -0.03 ... -0.14 -0.14
3 iframe= 1. delayh: -0.03 -0.04 ... -0.14 3.00
4iframe= 0. delayh: -0.03 -0.04 ... -0.14 -0.14
5 iframe= 1. delayh: -0.04 -0.05 ... -0.14 5.00
.....
26 iframe= 0. delayh: -0.14 -0.14 ... -0.14 -0.14
27 iframe= 1. delayh: -0.14 -0.14 ... -0.14 27.00
28 iframe= 0. delayh: -0.14 -0.14 ... -0.14 -0.14
29 iframe= 1. delayh: -0.14 -0.14 ... -0.14 29.00
30 iframe= 0. delayh: -0.14 -0.14 ... -0.14 -0.14
31 iframe= 1. delayh: -0.14 -0.14 ... -0.14 31.00

---------------------------------------------------------------------

The values of array "delayh" are not saved. (:-(

Annotations:

a) This error doesn't appear in my example, when the dimension "dim"
of the array delayh is less than 14

b) This error doesn't appear in ifort-version 8

How can Intel help?

[Kevin_D_Intel · Accepted solution]

Thank you for the nice reproducer.

The issue occurs when compiling sub_sub.f with both -save and -CB (i.e. -check bounds).

I would not rely on the "good" results you see with dim=13. That occurs only on IA-32 and I'd guess just by chance. On Intel 64, incorrect results occur with both dim=13 and dim=14 and the two options I noted.

Whatever the underlying defect is, it does not exist (on either IA-32 or Intel 64) in our next major release due out in a couple of months. As a work around, with the 11.1 compiler, you can compile without bounds checking until the next major release is available.

I will also direct this to Development to check whether we can fix this in an 11.1 update.

[mecej4]

The compiler option -CB is not very helpful in locating the bug in this program. However, -C is.

[bash]$ ifort -C -traceback savetest.f sub_sub.F
$ ./a.out
  1 iframe=  1. delayh: -0.02 -0.03 ... -0.14  1.00
forrtl: severe (193): Run-Time Check Failure. The variable 'sub_sub_$IFRAME' is being used without being defined
Image              PC        Routine            Line        Source             
a.out              0808E9BD  Unknown               Unknown  Unknown
a.out              0808D7B5  Unknown               Unknown  Unknown
a.out              0805A86F  Unknown               Unknown  Unknown
a.out              0804B397  Unknown               Unknown  Unknown
a.out              0804BAD2  Unknown               Unknown  Unknown
a.out              0804A25C  sub_sub_                   22  sub_sub.F
a.out              08049EEE  MAIN__                     12 savetest.f
a.out              08049E11  Unknown               Unknown  Unknown
libc.so.6          F760EC0E  Unknown               Unknown  Unknown
[/bash]

Once you fix the error shown by this run, you will repeat the procedure and obtain a similar message for DELAYH. That's the drawback of dynamic detection.

Even -C by itself will locate this error at runtime, but you will not be told on which line the error happened.

[Kevin_D_Intel]

You are overlooking compiling with -save.

[mecej4]

You are overlooking compiling with -save. Yes; I have edited/trimmed accordingly.

In #1 you wrote The issue occurs when compiling sub_sub.f with both -save and -CB (i.e. -check bounds). I think that -zero should have been added because, without that option, if the subroutine is called with rinp(1) different from 1.0 on the first call to it, iframe would be used uninitialized in Line-21.

Curiously, the compiler bug is not seen if, in addition, either the -g or -O0 option is used.

[Kevin_D_Intel]

I didn't mention -zero because it is not in play in relationto the defect being triggered, but I understand/agree with your assessment regarding iframe.

-g implies -O0. Disabling optimization is another work around if one needs -CB while developing the code further. Thanks for noting that.