One untyped variable causes access violation in compiler

The following test code causes FTN95 8.63 to abort with an access violation, with or without /64. The code has IMPLICIT NONE, and is missing a type declaration for the variable NSTATN.

Minor changes to the code cause the compiler to revert to normal behavior, with an error message for the undeclared variable.

      subroutine subx(nl, nu, sa33, sb33, v, nomega)
      implicit none
      real vwe2
      integer , intent(in) :: nl, nu, nomega
      real , intent(in) :: v
      real , intent(in) :: sa33(25,nomega), sb33(25,nomega)
      integer :: i   !, nstatn
      complex :: pitacc
      real , dimension(25) :: stemp
!-----------------------------------------------
      nstatn = 5        ! variable type not declared
      vwe2 = 1.5
      pitacc = 1.7
      do i = nl, nu
         stemp(1:nstatn) = -(sa33(1:nstatn, i)*(1.3-pitacc) + &
            3.2-vwe2*sb33(1:nstatn, i) * pitacc+v*sa33(1:nstatn, i)*3.2)
      end do
      print *,stemp(5)
      return
      end subroutine subx

mecej4

Thank you for the feedback. I have made a note of this.

mecej4

I have a potential fix for this bug. Do you have a test case that I can use to check the outcome?

Paul,

Here is a link to a zip containing two source files. It was by pruning these sources that I obtained the short test file in the initial report.

https://www.dropbox.com/s/wo6taralxbptmvy/lrao.7z?dl=0

The file modules.f90 needs to be compiled first to generate the *.mod files needed by lrao.f90.

You will see an access violation if you then attempt to compile lrao.f90.

0049c351 the_base_type(<ptr>structÄtype_definition) [+0035]
 00436085 base_tree_type(structÄtree_ptr) [+0030]
 00504d4a process_tree2(<ref>structÄtree_ptr,structÄtree_context) [+1439]
 00509faa flatten_plus(structÄtree_ptr,enumÄlogical,enumÄlogical)#56 [+01bf]
 00504d4a process_tree2(<ref>structÄtree_ptr,structÄtree_context) [+1439] [recur=  8] 
 0043a446 process_tree_completely(<ref>structÄtree_ptr) [+015a]
 00418615 end_function(int) [+0a7c]
 0041a4d0 parse_end_statement(<ptr>char,int,<ref>int) [+0c0d

mecej4

Thanks. I can see the access violation and I have a potential fix for it. The fix does not break our test suite but I don't know if the result of the computation will be correct.

Do you have test data and a simple main program that calls the subroutine lrao?

Unfortunately, the subroutine LRAO is part of a package with over 150 subroutines, and I have not yet been able to get the package to output reproducible results. I do not have a complete reference set of results, either.

One of the bad features of this package is that it has dozens of large COMMON blocks, and uses EQUIVALENCEd variables of different types to write (and later read back) entire block contents to scratch files. This feature does not allow FTN95's /undef to be used.

Thanks. I will go with my potential fix which I know works with the current test suite.

There were two source files in the package that FTN95 could not compile, one of which is LRAO.f90. Fortunately, I have now found a work-around: replace a couple of WHERE constructs with DO loops.

I get the following adaptation to fail with FTN95 8.62.0

I find that even when declaring INTEGER nstatn, I stll get an ICE. Changing pitacc to REAL or replacing 1:nstatn with do j = 1,nstatn both remove the ICE. subroutine subx(nl, nu, sa33, sb33, v, nomega) implicit none integer , intent(in) :: nl, nu, nomega real , intent(in) :: v real , intent(in) :: sa33(25,nomega), sb33(25,nomega) ! integer :: i, nstatn,j real :: vwe2 complex :: pitacc ! real :: pitacc real , dimension(25) :: stemp !----------------------------------------------- nstatn = 5 ! variable type not declared vwe2 = 1.5 pitacc = 1.7 do i = nl, nu ! ! stemp(1:nstatn) = -(sa33(1:nstatn, i)(1.3-pitacc) + & ! 3.2-vwe2sb33(1:nstatn, i) * pitacc+vsa33(1:nstatn, i)3.2) ! stemp(1:nstatn) = - ( sa33(1:nstatn, i) * (1.3-pitacc) & + 3.2 & - sb33(1:nstatn, i) * vwe2pitacc & + sa33(1:nstatn, i) * 3.2v ) ! do j = 1,nstatn stemp(j ) = - ( sa33(j , i) * (1.3-pitacc) & + 3.2 & - sb33(j , i) * vwe2pitacc & + sa33(j , i) * 3.2v ) end do ! end do print *,stemp(5) return end subroutine subx

Perhaps another example of complex * real error