Integer variable no longer usable after forall construct

[canavanin]

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.   
            do i=1,sp_basis%num_dim
---------------^
xyz.f90(1210): error #6063: An INTEGER or REAL data type is required in this context.   
        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):

[fortran]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[/fortran]

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):

[bash]ifort -c -g -C -check noarg_temp_created -traceback -warn -warn nodeclarations -nogen-interface xyz.f90[/bash]

Does any of you know what the problem might be?

Thanks a lot for your time!

[Steven_L_Intel1]

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.

[canavanin]

Dear Steve

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

File 1:

[fortran]program nocomp use modu implicit none integer :: arg2 = 1 allocate(public_spectra%basis(arg2)) call sub(arg2) deallocate(public_spectra%basis) end program nocomp[/fortran]
File 2:

[fortran]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 [/fortran]
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.

[Steven_L_Intel1 · Accepted solution]

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.

[canavanin]

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