Compiler errors with /warn:interfaces diagnostics option enabled

[jirina]

After reporting ICEs in the first release of XE 2011 to Premier Support, I followed the recommendation to disable /warn:interfaces as the workaround. I have been informed recently that issues reported by me were resolved in Update 2, so I enabled the option again. There are no ICEs now, however, I am getting strange/unexpected compiler remarks, warnings and errors which are not shown if /warn:interfaces is disabled.

I took my code and narrowed it down to following (please ignore if the code functionality makes sense; I simplified it by removing many lines of the original code), saved in the file 'functions.for':

[fxfortran]        
        subroutine fillFlow ( u, v, w, rho, cx, cy, cz )
        
        include 'frequent.inc'
        
        real*4 u(nx,ny,nz), v(nx,ny,nz), w(nx,ny,nz), rho(nx,ny,nz)
        
        real*8 cx(nx), cy(ny), cz(nz)
        
        real*8 massFlux, rhoNB
        
        logical*4 zeroFlow
        
        integer*4 i, j, k
        
        double precision wlm2
        
          
          do i=2,nx-1
          
            massFlux = 0.0d0
            
            do j=2,ny-1
            do k=2,nz-1
              u(i,j,k) = 1.0
              rhoNB = wlm2( dble(rho(i,j,k)), dble(rho(i+1,j,k)),
     +                      cx(i), cx(i-1) )
              massFlux = massFlux + u(i,j,k) * rhoNB * cy(j-1)*cz(k-1)
            enddo
            enddo
            
          end do
          
          return
        end
        
c ----------------------------------------------------------------------
        
        double precision function wlm2 ( x1, x2, w1, w2 )
        
        real*8 x1, x2, w1, w2
        
          wlm2 = ( w1*x1 + w2*x2 ) / (w1+w2)
        
          return
        end
        
c ----------------------------------------------------------------------
        
        subroutine readData (  )
        
        include 'switches.inc'

!dec$ if defined ( _DEV_ ) ! if this is commented out, everything is OK
!dec$ else
        include 'frequent.inc'
!dec$ endif
          
          return
        end[/fxfortran]

The include file 'frequent.inc' contains following:

[fxfortran]        integer*4 nx, ny, nz
        
        COMMON /FreqUsed/ nx, ny, nz[/fxfortran]

and the other include file, 'switches.inc' contains following:

[bash]!dec$ define _DEV_[/bash]

The compiler options are (I kept them the same as in my original, full project):
/nologo /debug:full /Od /fixed /extend_source:132 /Qopenmp /fpscomp:general /debug-parameters:used /warn:declarations /warn:truncated_source /warn:interfaces /assume:byterecl /module:"Debug\\\\" /object:"Debug\\\\" /Fd"Debug\\vc90.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:arg_temp_created /libs:static /threads /dbglibs /c /align:all /heap-arrays

Compiling 'functions.for' yields following remarks, warnings and errors:

------ Build started: Project: XE Update 2 Test, Configuration: Debug|Win32 ------

Compiling with Intel Visual Fortran Compiler XE 12.0.2.154 [IA-32]...
functions.for
D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for(6): remark #5082: Directive ignored - Syntax error, found '*' when expecting one of: :
D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for(25): error #6410: This name has not been declared as an array or a function.
D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for(26): warning #6717: This name has not been given an explicit type. [RHO]
D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for(28): warning #6717: This name has not been given an explicit type.
D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for(2): warning #6717: This name has not been given an explicit type.
D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for(2): warning #6717: This name has not been given an explicit type.
compilation aborted for D:\\Source_Fortran\\Intel\\XE Update 2 Test\\functions.for (code 1)

XE Update 2 Test - 2 error(s), 4 warning(s)

---------------------- Done ----------------------

The whole small project is attached to this post.

I realized that I can get rid of the remark and errors by:
- Commenting out the line which calculates rhoNB in the subroutine fillFlow (which I of course do not want).
- Commenting out the conditional compilation lines in the subroutine readData.

However, I would like to keep the existing code and find the real cause why compiler is having problems with my code.

[Steven_L_Intel1]

That is bizarre! I will pass this on to the developers and let you know what we find. Issue ID is DPD200166831.

[Steven_L_Intel1]

The developers have fixed this, but I don't yet know when the fix will appear. I'll update this when I learn more.

[jirina]

Thank you very much; I am looking forward to the fix. Anyway, it is not so critical for me now, so I can wait for the fix to become available.

[Steven_L_Intel1]

I expect the fix for this to appear in Update 4.

[jimdempseyatthecove]

What happens if you add one or more blank lines to the bottom of frequent.inc?

I've seen issues in other compilers where include files exhibit problems where end of file ends at end of line of valid statement.

(do the same with your other ...inc files if this hack works)

Jim Dempsey

[jimdempseyatthecove]

Also,

With the original files, what happens if you perform a Clean, then Build?

i.e. Were the symptoms caused by

When changing the conditional compile macro in nested include files

Then did the compiler not see the dependency change
and therefore did not rebuid an auto-generated interfaces .mod file

Jim Dempsey

[Steven_L_Intel1]

The problem in this case has nothing to do with auto-generated interfaces. Simply enabling the /warn:interface option and compiling the source is enough to trigger the bug, which can appear if you use INCLUDE. Disabling that option for now is the workaround.

[jirina]

Indeed, cleaning and building does not help, and also, all my .for and .inc files always have an extra empty line at their end. Anyway, thank you, Jim, for your suggestions, and thank you, Steve, for letting me know about the status of this issue. I am looking forward to the Update 4 with the fix.