[Bug fortran/57023] New: [4.7/4.8/4.9 Regression] Not packing arrays with changing variable used for size

tkoenig at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sun Apr 21 11:13:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57023

             Bug #: 57023
           Summary: [4.7/4.8/4.9 Regression] Not packing arrays with
                    changing variable used for size
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tkoenig@gcc.gnu.org


Doing what the program below does is _extremely_ bad style -
changing n which is used for specifying the array size.

However, I think it is legal, and the expected output
is

1 1 1 1 0
1 1 1 1 0
1 1 1 1 0
1 1 1 1 0
0 0 0 0 0

Actual output is

 1 1 1 1 1
 1 1 1 1 1
 1 1 1 1 1
 1 0 0 0 0
 0 0 0 0 0

module mymod
contains
  subroutine foo(a,n)
    integer, dimension(n,n), intent(inout) :: a
    integer :: n
    n = n - 1
    call baz(a(1:n,1:n),n)
  end subroutine foo

  subroutine baz(a,n)
    integer, dimension(n,n), intent(inout) :: a
    a = 1
  end subroutine baz
end module mymod

program main
  use mymod
  integer, dimension(5,5) :: a
  n = 5
  a = 0
  call foo(a,n)
  print '(5I2)',a
end program main

The problem is in gfc_full_array_ref_p, which uses gfc_dep_compare_expr
to compare the upper bounds (n against n) without noting that n
has been changed in the meantime.

Proposed solution:

a) Always warn about such horrible code

b) If something like that happens, don't assume a full reference,
   and don't set the contiguous argument to gfc_full_array_ref_p to
   true.

The code was introduced in rev. 156749, btw, quite some time ago.



More information about the Gcc-bugs mailing list