https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99506
--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Wed, Mar 10, 2021 at 08:39:19AM +0000, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99506 > > --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- > This is a frontend issue, the FE produces an invalid static initializer for > 'latt' (DECL_INITIAL): > > {(real(kind=8)) latt100[(integer(kind=8)) i + -1] / 1.0e+2, (real(kind=8)) > latt100[(integer(kind=8)) i + -1] / 1.0e+2,... } > > if this should be dynamic initialization FEs are responsible for lowering > this. > > I don't know fortran enough for what 'parameter' means in this context: > > real(double), parameter:: latt(jmax) = [(latt100(i)/100.d0, j=1,jmax)] > > but the middle-end sees a readonly global (TREE_STATIC) variable. > 'parameter' means that latt(jmax) is a named constant array. Haven't thought about it too much, but for comparison, it should be equivalent to C's 'static const latt[jmax] = {1, 2, ...}'. This bug likely goes back to when g95 was initially added to GCC. Implied-do loops are a rather special/odd construct. AFAI[CT|K], gfortran has never done a proper checking of the ac-value-list (See F2018, R773). Here, the ac-value is the expression 'latt100(i)', which must reduce to a constant expression because the implied-do loop appears in an initialization expression. Well, 'i' is an uninitialized variable, which certainly is not constant.
