Bug in -assume realloc_lhs

[John4]

Hi,

With the latest compiler, and the code below, I get garbage output.

program test_lhs_allocate

    use iso_fortran_env

    implicit none

    type :: table
        character(63) :: name = ''
        character(63), allocatable :: alias(:)
    end type

    integer :: i, j
    type(table), allocatable :: list(:)
    type(table) :: item

    allocate (list(1:0))    !empty list

    item%name = 'name'
    item%alias = [character(63) :: 'label']
    list = [list, item]

    item%name = 'id'
    item%alias = [character(63) :: ]
    list = [list, item]


    item%name = 'status'
    item%alias = [character(63) :: 'state', 'validity', 'test']
    list = [list, item]

    item%name = 'other'
    item%alias = [character(63) :: 'extra', 'additional', 'more']
    list = [list, item]


    do i = 1, SIZE(list)
        write (OUTPUT_UNIT, '(/"name: ", A,/,"aliases: ", *(A,:,","))') &
            TRIM(list(i)%name), &
            (TRIM(list(i)%alias(j)), j = 1, SIZE(list(i)%alias))
    enddo

end program test_lhs_allocate

This is the output I get with both ifort 15.0 and gfortran 4.9 (invalid characters trimmed from output when using ifort):

~$ ifort -standard-semantics test_lhs_allocate.f90 
~$ ./a.out 

name: name
aliases: 

name: id
aliases: 

name: status
aliases:                                ,                                         ?

name: other
aliases: extra,additional,more
~$ gfortran test_lhs_allocate.f90 
~$ ./a.out 

name: name
aliases: label

name: id
aliases: 

name: status
aliases: state,validity,test

name: other
aliases: extra,additional,more

I'm not sure if I already reported this, so I apologize in advance if I did.

 

[IanH]

Perhaps https://software.intel.com/en-us/articles/incorrect-results-assigning-array-constructor-with-allocatable-components

[John4]

The reason for my doubt, is that I reported the same thing to gfortran's developers last year, so either it worked with ifort before (and it's a regression), or I reported it here as well and it got lost (since I don't see any of my posts from 2013 in the history).
 

[IanH]

There could be (or have been) multiple things going wrong, but in general "assigning the results of an array constructor that is of a type with allocatable components to an allocatable array of that same type" is something that has been broken in ifort in some way for quite a few years now.  To make things always seem new and exciting I am hardwired to forget this at regular intervals - I probably have gone through the motions of chopping out a reproducer about a dozen times (and in a few cases actually made it all the way to through to a premier support report or a forum post) before I start paying attention to that nagging feeling of déjà vu.

[Kevin_D_Intel]

It appears the newest 15.0 and earlier ifort releases produce incorrect results. I'll see whether you reported this before and whether it relates to the defect Ian cited. If not then I will report this to Development for some further analysis. Stay tuned....

[Kevin_D_Intel]

I did not find any previous report from you (John) on this. This is the history of the reports I found:

https://software.intel.com/en-us/forums/topic/285920 (Ian’s original bug report)
https://software.intel.com/en-us/forums/topic/270989
https://software.intel.com/en-us/forums/topic/271448 (the second bug reported in the thread)

Your issue is related to the earlier reports and same underlying defect. As shown below, the suggested work around at the defect Ian cited is usable in your case. I associated this thread with the internal tracking id noted below and will update you about on a fix once available.

(Internal tracking id: DPD200166796)

program test_lhs_allocate

    use iso_fortran_env

    implicit none

    type :: table
        character(63) :: name = ''
        character(63), allocatable :: alias(:)
    end type

    integer :: i, j
    type(table), allocatable :: list(:), list_temp(:)
    type(table) :: item

    allocate (list(1:0))    !empty list

    item%name = 'name'
    item%alias = [character(63) :: 'label']
#ifdef DPD200166796
    list_temp = [list, item]          ! patch for DPD200166796
    call move_alloc(list_temp, list)
#else
    list = [list, item]               ! original stmt
#endif

    item%name = 'id'
    item%alias = [character(63) :: ]
#ifdef DPD200166796
    list_temp = [list, item]          ! patch for DPD200166796
    call move_alloc(list_temp, list)
#else
    list = [list, item]               ! original stmt
#endif


    item%name = 'status'
    item%alias = [character(63) :: 'state', 'validity', 'test']
#ifdef DPD200166796
    list_temp = [list, item]          ! patch for DPD200166796
    call move_alloc(list_temp, list)
#else
    list = [list, item]               ! original stmt
#endif


    item%name = 'other'
    item%alias = [character(63) :: 'extra', 'additional', 'more']
#ifdef DPD200166796
    list_temp = [list, item]          ! patch for DPD200166796
    call move_alloc(list_temp, list)
#else
    list = [list, item]               ! original stmt
#endif


    do i = 1, SIZE(list)
        write (OUTPUT_UNIT, '(/"name: ", A,/,"aliases: ", *(A,:,","))') &
            TRIM(list(i)%name), &
            (TRIM(list(i)%alias(j)), j = 1, SIZE(list(i)%alias))
    enddo

end program test_lhs_allocate

The work around below can be used with 15.0 and earlier compiler versions.

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.090 Build 20140723

$ ifort -fpp -standard-semantics u532447.f90
$ ./a.out

name: name
aliases: ▒

name: id
aliases:

name: status
aliases:                                Г▒?▒,?,                                         ?

name: other
aliases: extra,additional,more


$ ifort -fpp -DDPD200166796 -standard-semantics u532447.f90
$ ./a.out

name: name
aliases: label

name: id
aliases:

name: status
aliases: state,validity,test

name: other
aliases: extra,additional,more

[John4]

I have the test_lhs_allocate.f90 file in my test-ifort directory, so maybe I just thought of reporting it, but didn't (it has happened in the past).

I already have a generic subroutine (i.e., one whose body of work is an include file) to expand any array using the MOVE_ALLOC, so this might just be déjà vu like IanH says.

My generic has issues (i.e., leaks memory) when the type being expanded implements a deferred assignment, and that's why I tried explicit reallocation again ---but that led to the ICE I reported recently.

Anyway, thanks for providing an internal tracking ID.