Showing results for 
Search instead for 
Did you mean: 

Deallocation issues with PS2018

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(:)

! 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
if(istat.eq.0) then
  ! Initialise array
  a1%array = 0
! This should deallocate a%array
  a1 = a0

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

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

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


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.

0 Kudos
3 Replies

I have just noticed another

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.

0 Kudos
Black Belt

I'm not seeing the

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.

Steve (aka "Doctor Fortran") -
0 Kudos

For a potential work around,

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

0 Kudos