Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

Deallocation issues with PS2018

New Contributor II

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
New Contributor II

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.

Black Belt Retired Employee

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.

Black Belt

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