Deallocation issues with PS2018

[Stephen_Sutcliffe]

I have noticed a change in behaviour in my application when I recompiled used the latest version (PS 2018).

I have lots of user defined data types that have within them allocatable components and I often create a "NULL" entity that is used to initialise the other instances used throughout the program by the following statement :

a = a_NULL 

where a is the instance being initialised and a_NULL is an instance of the data structure with all components uninitialized.

The follow test example shows the change between compilers.

program test
  
implicit none
  
! Simple data structure with allocatble component
type dtyp
  integer             :: id = 0   ! This does not seem to work
  integer,allocatable :: array(:)
endtype

! Create instances
type(DTYP)   :: a0,a1
character(1) :: wt
integer      :: istat
  
! Initialise (doesn't use the initialisation in type definition
a1%id = 1
a0%id = 0

! Allocate array in a1
allocate(a1%array(10),stat=istat)
if(istat.eq.0) then
 
  ! Initialise array
  a1%array = 0
  
! This should deallocate a%array
  a1 = a0

! Shows as deallocated in debugger
  
  ! Try reallocation  
  allocate(a1%array(10),stat=istat)
  if(istat.eq.0) then
    a1%array = 0
  else
  ! Fails with status 151 (Already allocated)
    write(*,'(a)') 'Reallocation failed!'
  endif

else
  
  write(*,'(a)') 'Allocation failed!'
  
endif 

write(*,'(a)') 'Press any key to exit'
read(*,'(a)') wt

end  

In PS 2017 the test runs to the end without any errors, however in PS 2018 the test fails to allocate the a%array component the second time around as it still thinks it is already allocated. Interestingly the debugger shows a%array to not be allocated.

Is this something I am doing wrong that I have got away with in the past or is it a potential bug in the compiler?

If it is the later I will have to revert back to PS2017 until it is fixed.

On a more general note, why doesn't the initialisation of id = 0 in the definition work? The debugger shows garbage values until I explicitly assign 0. This is not dependent upon which compiler I use.

[Stephen_Sutcliffe]

I have just noticed another recent thread which covers a similar deallocation problem. In one reply Steve Lionel (Ret) seems to think it is a compiler bug and the original poster has already reported to the Intel development team though they have not confirmed anything yet.

[Steve_Lionel]

I'm not seeing the initialization issue you describe. You have "default initialization" for component id, and in all cases I try, this works,. I even moved the code into a subroutine so that a0 and a1 were local variables, and the default initialization was applied, as evidenced both in the debugger and by adding a print statement before the explicit assignment. I also tried non-zero values just to make sure I wasn't seeing an accidental initial value.

The issue with the deallocation on assignment of a1%array is there, though. I notice that the generated code calls a new library routine for_alloc_assign_v2 to do all the work - this evidently has a bug in the case of an allocatable component. I think this is the same issue as the other thread.

[jimdempseyatthecove]

For a potential work around, consider creating your dtyp a_NULL containing an id = a code indicating not to be used .AND. an allocated array containing 1 cell. As a debugging aid, you could allocate array(-999999999:-999999999), IOW a one element array with indices likely to trap on runtime check for index out of bounds. The id for not to be used could be -999999999.

This also means that you code should not use IF(allocated(var%array)), but rather use IF(var%id /= a_NULL%id).

Jim Dempsey