https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128235
Bug ID: 128235
Summary: Wrong bounds after ALLOCATE with SOURCE= or MOLD= from
a vector-subscripted array section
Product: gcc
Version: 16.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
When an ALLOCATE statement gives no shape for the object and its SOURCE= is an
array section with a vector subscript, the object gets the lower bound 0
instead of 1.
The values are correct, only the array bounds look wrong.
F2018 9.7.1.2: "When an ALLOCATE statement is executed for an array with no
allocate-shape-spec-list, the bounds of source-expr determine the bounds of
the array." b(idx) is an array section, so LBOUND(b(idx),1) is 1 and
UBOUND(b(idx),1) is 3.
program p
integer, allocatable :: idx(:), a(:), b(:)
b = [(j,j=1,10)]
idx = [2,5,6]
allocate(a,source=b(idx))
if (lbound(a,1)/=1) error stop 1
if (ubound(a,1)/=3) error stop 2
if (size(a)/=3) error stop 3
if (any(a/=idx)) error stop 4
stop 0
end program p
With gfortran 16.2.0 this stops with ERROR STOP 1 (lbound 0, ubound 2).
Fails on all versions of gfortran from 12 to 16 and trunk.
Check 4 passes: only the bounds are wrong.
https://godbolt.org/z/9d1dzqvfr
Other observations:
- MOLD=b(idx) gives the same wrong bounds.
- [FROM SWEEP: rank 2, m(:,idx)]
- The element type does not matter: integer, real, character, and a derived
type with or without allocatable components all fail.
- The optimization level does not matter: -O0 and -O3 give the same result.
- -fcheck=bounds does not report a(1), because the descriptor is
self-consistent (0:2). It reports only a(3).
- The bounds are correct when the shape is given
(allocate(a(3), source=b(idx))) and when the source is an expression
(source=b(idx)+0). [FROM SWEEP: triplet section b(2:4)]
Possibly related: PR67125 has the same symptom (lower bound 0 in place of 1)
for SOURCE= a function result without a descriptor. r265212 fixed that case in
2018, but PR67125 is still NEW.
PS: I'm cc'ing [email protected] as there's ongoing similar work on PR 128033.
Thank you,
Federico
