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.
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.
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.
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).