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: unassig...@gcc.gnu.org
ReportedBy: tkoe...@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.
