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.

Reply via email to