forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

ICE - local variable same name as derived type component

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1411

PostPosted: Tue Apr 07, 2020 12:00 pm    Post subject: ICE - local variable same name as derived type component Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6511
Location: Salford, UK

PostPosted: Tue Apr 07, 2020 2:18 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2217
Location: Sydney

PostPosted: Tue Apr 07, 2020 2:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1411

PostPosted: Tue Apr 07, 2020 4:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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