Question

I have an integer variable that is declared at the head of my subroutine. After I’ve used it as a control variable inside a forall construct, I can no longer use it as the control variable of a do loop. The compiler (Intel, v. 12.0.3) complains

xyz.f90(1210): error #6404: This name does not have a type, and must have an explicit type.   [I]
            do i=1,sp_basis%num_dim
---------------^
xyz.f90(1210): error #6063: An INTEGER or REAL data type is required in this context.   [I]
        do i=1,sp_basis%num_dim

I have tried to write a small example to replicate this behaviour (and compiled the file with the same compiler options as the actual problematic one, apart from -c), but this compiled & worked nicely, so below is my (slightly shortened) problematic code (implicit none applies to the entire module this code belongs to):

subroutine xyz(stuff)

   use data, only: ppm, npeaks

   ! some declarations
   integer :: i ! ...

   associate(sp_basis => public_spectra%basis(counter))

      spots = npeaks * np

      allocate(ref_curves(spots,npeaks,sp_basis%num_dim), stat=stat)
      if (stat.ne.0) then
         ! ...
      end if

      forall (i=1:max_dim) uppers(i) = ubound(sp_int%int,i)
      forall (i=1:max_dim) lowers(i) = lbound(sp_int%int,i)
      forall (i=1:npeaks,j=1:sp_basis%num_dim) peak_pos_hertz(j,i) = ppm_to_hertz(ppm(permutation(j),i), sp_axes(j))

      do peak_considered=1,npeaks
         do pos=(peak_considered-1)*np+1,peak_considered*np
            do i=1,sp_basis%num_dim   ! <-- COMPLAINT

If I change i to a name that was not used as a forall construct’s control variable everything works. Also, this is the second time I’ve run into this problem.

This is how the compilation is done (xyz.f90 is one of many files that make up the entire program):

ifort -c -g -C -check noarg_temp_created -traceback -warn -warn nodeclarations -nogen-interface xyz.f90

Does any of you know what the problem might be?

Thanks a lot for your time!

Answer 1

For all those interested, it’s a bug in the Intel compiler. Here you can read more about it. Also it sounds like this bug will be fixed in a compiler version that is to be released some time in 2012.