Integer variable no longer usable after forall construct

Integer variable no longer usable after forall construct

I'm using the compiler for Linux, version 12.0.3. My problem is as follows: 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 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!

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Without a compilable example to try, all I can suggest is to install the most recent update (Update 10, 12.1.4) and see if the problem is still there. I looked through our bug database and did not find anything similar, though the complaint seems vaguely familiar to me.

Steve - Intel Developer Support

Dear Steve

Thank you very much for your reply. Here is an example which produces the error I mentioned.

File 1:

program nocomp
use modu
implicit none
integer :: arg2 = 1 
allocate(public_spectra%basis(arg2))
call sub(arg2)
deallocate(public_spectra%basis)

end program nocomp

File 2:

module modu
implicit none
type spect

   integer, allocatable :: basis(:)

end type spect
type(spect), public :: public_spectra
contains
subroutine sub(arg2)
   integer, intent(in) :: arg2

   integer             :: i, uppers(4)
   associate(sp_basis => public_spectra%basis(arg2))
      forall (i=1:4) uppers(i) = i 
      do i=1,3

         print *, i

      end do

   end associate

end subroutine sub 
end module modu


I noticed that the error disappears if I don't use "associate", or if I omit "implicit none" from the module file; furthermore, I have failed to reproduce the error if I included the offending code with the main program, either using or not using "associate".

Also the compiler options do not seem to matter.

Many thanks for your effort.

c.

Best Reply

Thanks - I knew this sounded familiar. It is a bug that has been fixed for a release later this year. The issue ID is DPD200215341. The bug appears under very particular circumstances:

  1. You have a FORALL inside an ASSOCIATE construct
  2. The FORALL index variable is a name that is also used elsewhere within the ASSOCIATE construct
  3. IMPLICIT NONE is in effect

The workaround is to pick a FORALL index name that is not otherwise used in the ASSOCIATE. In your example, if you change the FORALL to be as follows:

forall (j=1:4) uppers(j) = j

with an appropriate declaration of j as integer, then it compiles ok.

Steve - Intel Developer Support

Thanks very much for your help, I'm glad that it's not one of my home-made bugs :)

Leave a Comment

Please sign in to add a comment. Not a member? Join today