ICE - local variable same name as derived type component

The following cut-down code has a local array, CNODE, which has the same name as a component of the derived type ROTMAT.

module lx_types
   implicit none
   
   type :: rotmat
      integer :: kcon
      integer, allocatable :: cnode(:)
   end type rotmat
   
end module lx_types

module blocks
   use lx_types
   implicit none
   type (rotmat) :: rotm
end module blocks

subroutine rot_stn(stn_a, stn_r)

use blocks, only: rotm
implicit none

integer  ::  i, nc, ncn, stn_a, stn_r
real, allocatable  ::  cnode(:)

ncn = rotm%kcon
nc = 0
if ( ncn > 0 ) then
   allocate (cnode(ncn))
   cnode = rotm%cnode
   do i = 1, ncn
      if ( cnode(i) <= stn_a ) nc = nc + 1
   enddo
   deallocate (cnode)
endif
stn_r = stn_a - nc

end subroutine rot_stn 

When the code is compiled without /check, there is no problem, other than a misspelled word, 'auotmatically', in a warning message.

When /check or /checkmate is specified, with or without /64, an internal compiler error occurs.

I used the recently released Version 8.61.

mecej4

Many thanks for the feedback.

This code also fails for me at v8.61 but not when using the current developers' version. So the issue appears to have already been resolved.

Independent of the ICE, I find the use of 'integer, allocatable :: cnode(:)' in 'type :: rotmat' to have practical limitations, as there is a significant memory overhead in describing the allocatable size of 'cnode', independent of your use of 'kcon'. My recollection is there is about 80 bytes per array, although this depends on the rank of the allocatable array. So if kcon is going to vary, say from 1:20, and with little sparsity, it may be simpler to define a fixed size array and avoid problems with allocatable components of a derived type and issues of deallocate. I removed this allocatable approach for lists of nodes for a general component/element, but kept it for larger arrays.

Haven't we seen this problem before ? (where real = integer ) (and possibly my comment ?)

changing to 'integer, allocatable :: cnode(:)' fixes the ICE, identifying it's source, which does need fixing.

changing to 'real, allocatable :: clnode(:)' , ie using a different local name retains the ICE.

We may have seen this problem before, but it could certainly not have been with V 8.61, which was released in the Personal edition just a few days ago.

The derived types in the actual application code have many more components and there are many such types with allocatable array components. The code runs quite fast when /check is not used, as compared to runs from other compilers with the same data files.