allocatable array assignment error

allocatable array assignment error


the following program displays behavior that I don't understand.

module type_mod 
    type mytype 
        real, dimension(:,:,:,:,:,:), allocatable:: a 
            procedure :: allocate 
    end type mytype 
    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) 
    n1=size(t%a,1); n2=size(t%a,3); n3=size(t%a,4); n4=size(t%a,6) 
    case =2 
    select case (case) 
        a2= t%a(:,2,:,:,i,:)  ! this works 
        a2= 1.0*t%a(:,2,:,:,i,:) ! this does NOT work 
        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 

Compile with bounds checking, allowing for Fortran 2003 reallocation of allocatable arrays on assignment, e.g.:
ifort -g -check bounds -assume realloc_lhs -o "main.o" "../main.f90" 

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

*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

Thanks in advance!


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

16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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.

Retired 12/31/2016

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:

program main

  implicit none
  real, allocatable:: a(:,:)

  real, allocatable :: a2(:)

  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

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

I have reproduced the error on ifort version 12.1.2 also

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

Retired 12/31/2016

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.

Retired 12/31/2016



A = (B(:,:,3,:)) + 1

work as well?

Jim Dempsey

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

Retired 12/31/2016

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

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. 

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

Retired 12/31/2016

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.

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

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

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

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.

Retired 12/31/2016

Thanks Steve, great news!

Leave a Comment

Please sign in to add a comment. Not a member? Join today