[Bug fortran/106684] New: inconsistent array initialization

[jorn--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

Bug ID: 106684
   Summary: inconsistent array initialization
   Product: gcc
   Version: 10.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j...@bolding-bruggeman.com
  Target Milestone: ---

The minor update of 10.3 to 10.4 causes gfortran to no longer accept
initialization of multidimensional array components with 1d data. However,
standalone multidimensional arrays can still be initialized with 1d data. That
seems inconsistent. The same behavior is found in recent releases of 11 and 12
(tested: 11.3.0, 12.1.0)

Example:

program p
   implicit none

   real :: a(2,2)
   data a /0., 1., 2., 3./

   type t
  integer :: b
  real :: a(2,2)
   end type
   type (t) c
   data c /t(1, (/0., 1., 2., 3./))/
end program

This results in the following error with gfortran 10.4:

test_array_init.F90:12:16:

   12 |data c /t(1, (/0., 1., 2., 3./))/
  |1
Error: The rank of the element in the structure constructor at (1) does not
match that of the component (1/2)

However, the above code is accepted by gfortran 9.x and 10.3, as well as ifort.

[Bug fortran/106684] inconsistent array initialization

[jorn--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #2 from Jorn Bruggeman  ---
I interpret the quoted F2018, 7.5.10 as "the same rules should govern
initialization of components of derived types and initialization of stand-alone
variables". That was previously (in 10.3, 11.2, and other compilers such as
ifort) the case: multidimensional arrays could be initialized with 1d data,
whether they were stand-alone variables or components of a derived type (note
that it was not just accepted by the compiler - it worked fine too). Now, in
10.4 and 11.3, that is no longer the case: the requirements on initialization
of type components have become more stringent as they demand the expression to
have the same rank. Assignments to stand-alone variables can still have
different rank.

Are you effectively saying that 10.3 and 11.2 (as well as all ifort versions I
am aware of) are too forgiving in both cases (accepting data of different rank
as long at the totals number of elements is the same), while 10.4 and 11.3 are
still too forgiving when it comes to stand-alone array variables?

Adding reshape does work - but it means the shape needs to be repeated twice,
once in the declaration and once in the assigned value, which seems suboptimal.

[Bug fortran/106684] inconsistent array initialization

[jorn--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #5 from Jorn Bruggeman  ---
Thanks; it does look like older gfortran versions (and ifort) are too forgiving
here, and that, given the F2018 definition of "conformable", the latest
gfortran releases are correct.

As for "stand-alone" variables, I just means regular variables (i.e., not a
component of a derived type). What surprised me is that this still compiles
fine in latest gfortran versions:

program p
   implicit none

   real :: a(2,2)
   data a /0., 1., 2., 3./
end program

with the data assigned to "a" seemingly being of rank 1. However, this seems to
work because the rules governing "data" statements for arrays explicitly
describe the target elements ("a") being unpacked in array order, and the total
number of values having to match.

Conversely, this is [correctly] rejected by the latest gfortran versions:

program p
   implicit none

   real :: a(2,2) = (/0., 1., 2., 3./)
end program

All in all, I accept this change in 10.4 and 11.3 was not a bug but an
improvement. It unfortunately does mean that the code (not my own, but one I
depend on) will need changes in >100 places...

[Bug fortran/106684] inconsistent array initialization

[jorn--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684

--- Comment #7 from Jorn Bruggeman  ---
None from me; thanks for the explanation!