allocatable array assignment error

[dan0112]

Hi

the following program displays behavior that I don't understand.
[fortran]
module type_mod
    type mytype
        real, dimension(:,:,:,:,:,:), allocatable:: a
        contains
            procedure :: allocate
    end type mytype

    contains
    subroutine allocate(this,n1, n4)
        class(mytype), intent(inout):: this
        integer , intent(in) :: n1, n4
        integer, parameter :: n2= 5, n3=5

        if (.not. allocated(this%a)) allocate(this%a(n1,n2,n3,n4,10,10))

    end subroutine allocate
end module type_mod

program main
    use type_mod
    implicit none
    type(mytype) :: t
    real, allocatable :: a2(:,:,:,:)
    integer:: n1, n2, n3,n4, i, case

    call t%allocate(5,5)
    t%a=10.0

    n1=size(t%a,1); n2=size(t%a,3); n3=size(t%a,4); n4=size(t%a,6)
    allocate(a2(n1,n2,n3,n4))

    i=2

    case =2
    select case (case)
    case(1)
        a2= t%a(:,2,:,:,i,:)  ! this works
    case(2)
        a2= 1.0*t%a(:,2,:,:,i,:) ! this does NOT work
    case(3)
        a2(:,:,:,:)= 1.0*t%a(:,2,:,:,i,:) ! this works
    end select

    print*, n1,n2,n3,n4
    print*, shape(a2)
    print*, a2(1,2,3,4)

end program main
[/fortran]
Compile with bounds checking, allowing for Fortran 2003 reallocation of allocatable arrays on assignment, e.g.:
[bash]
ifort -g -check bounds -assume realloc_lhs -o "main.o" "../main.f90"
[/bash]
Output is:

           5           5           5          10
           5           1           5           5
forrtl: severe (408): fort: (2): Subscript #2 of the array A2 has value 2 which is greater than the upper bound of 1

Traceback indicates the line containing  print*, a2(1,2,3,4) as the source of the violation.

If you set case=1 or case=3, I get the expected output:

           5           5           5          10
           5           5           5          10
   10.00000


*The question*: Why do I get the error in case=2 ?


*More information*: Not allowing for the Fortran 2003 reallocation on assignment yields the expected results in all cases. Turning off bounds checking yields somewhat strangely:

           5           5           5          10
           5           1           5          10
   10.00000


Thanks in advance!

Daniel

PS: I am using Intel composer_xe_2013.0.079 on Ubuntu 12.04

[Steven_L_Intel1]

Thanks for the interesting test case. I can reproduce the problem and have escalated it as issue DPD200238279. I will update this thread with any progress.

[dan0112]

The guys at the comp.lang.fortran (CLF) newsgroup think this is a compiler bug. They provided a much simpler program that displays the same error: [fortran] program main implicit none real, allocatable:: a(:,:) real, allocatable :: a2(:) allocate(a(5,6)) a =10.0 a2 = 1.0 * a(2,:) print "('shape of ',A,T30,*(I2,:,','))", & 'a(2,:))', shape(a(2,:)) print "('shape of ',A,T30,*(I2,:,','))", & '1.0 * a(2,:)', shape(1.0 * a(2,:)) print "('shape of ',A,T30,*(I2,:,','))", & 'a2', shape(a2) print *, a2(6) end program main [/fortran] [bash] >ifort /check:all /warn:all /standard-semantics "2012-11-08 danielh.f90" && "2012-11-08 danielh.exe" Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.0.1.119 Build 20121008 ... shape of a(2,:)) 6 shape of 1.0 * a(2,:) 6 shape of a2 1 forrtl: severe (408): fort: (2): Subscript #1 of the array A2 has value 6 which is greater than the upper bound of 1 [/bash]

[dan0112]

I have reproduced the error on ifort version 12.1.2 also

[Steven_L_Intel1]

I have no doubt it's a compiler bug. Thanks for the simpler example.

[Steven_L_Intel1]

We have a fix for this, but it's fairly complex and it will have to wait for a major release later this year. The problem occurs when you have an assignment of the form: A = B(:,:,3,:) + 1 where the subscripts of B are colons except for one that is a scalar, and the array section is combined with an arithmetic operator. In this case, the shape of the section is not properly computed for the purpose of the automatic reallocation of the left side. A workaround is to split the operation in two, such as: A = B(:,3,:,:) A = A + 1 We have confirmed that our fix handles both test programs, and appreciate your bringing this to our attention. We're somewhat astonished that this hasn't been reported before - the bug has been there for many years.

[jimdempseyatthecove]

Steve, Would A = (B(:,:,3,:)) + 1 work as well? Jim Dempsey

[Steven_L_Intel1]

As far as I know, no, that would not work.

[dan0112]

It seems that the bug is still present in ifort version 13.1.1? Any plans on when the fix will come out?

[TimP]

In my testing of problems with allocate, the best recent version is the current 13.1.192.  I and my customers have had several problem reports closed without consultation with partial fixes and now have new ones opened against the (now closed) beta test.

Frequent symptoms are that adding or removing -g along with -O2 -openmp will move allocation in or out of a following DO loop.  It seems more reliable without -openmp.

Problems with automatic and allocatable are similar. 

[Steven_L_Intel1]

When I said "a major release later this year", I was referring to compiler version 14, due out in September.

[dan0112]

From the list of bug fixes, it looks like this has been fixed in the most recent release, i.e. in Intel® Fortran Composer XE for Linux* 2013 SP1. Is this correct? My institution does not yet have access to that update so I can't test.

[TimP]

The smaller case posted by dan0112 encounters similar problems with 13.1.192 and 14.0.080 Intel64 compilers.

[dan0112]

This would be very bad news. The bug fix list I was referring to is here

http://software.intel.com/en-us/articles/intel-composer-xe-2013-compilers-sp1-fixes-list

Going through it, I found the following entry, which I thought was the fix for this issue:

DPD200238279 Fortran Automatic reallocation gives wrong bounds when RHS is expression

[Steven_L_Intel1]

dan0112, I verified that 14.0 correctly compiles both sources you posted. I'm not sure what Tim tried - perhaps he forgot to use -assume realloc_lhs.

[dan0112]

Thanks Steve, great news!