|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1887
|
Posted: Tue Apr 07, 2020 12:00 pm Post subject: 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.
Code: | 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Tue Apr 07, 2020 2:18 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2555 Location: Sydney
|
Posted: Tue Apr 07, 2020 2:30 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1887
|
Posted: Tue Apr 07, 2020 4:06 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|