On Tue, Nov 15, 2022 at 06:31:16PM -0800, Steve Kargl via Fortran wrote:
> On Tue, Nov 15, 2022 at 05:13:19PM -0800, Steve Kargl via Fortran wrote:
> > F2008 introduced the inclusion of a typespec in a forall
> > statement, and thn F2018 a typespec was allowed in an
> > implied-do. There may even be a few bug reports.
> >
>
> Forgot to ask. Anyone know how namespaces work with
> initialization expressions in gfortran? This code
> should compile
>
> program foo
> use iso_fortran_env, only : k => real_kinds
> implicit none
> integer, parameter :: n = size(k)
> integer, parameter :: &
> & p(n) = [(precision(real(1.,k(i))), integer :: i = 1, n)]
> print '(*(I0,X))', p
> end program foo
>
>
> The first occurence of 'i' in the expression for 'p(n)'
> is either thought to be in a different namespace, or
> an implied-do loop cannot be used in an initialization
> expression.
After spending to much time on this, I found that decl.cc:3044-50
m = gfc_match_init_expr (&initializer);
if (m == MATCH_NO)
{
gfc_error ("Expected an initialization expression at %C");
m = MATCH_ERROR;
}
results in m == MATCH_ERROR. First, I would expect the "if"
condition to include the m == MATCH_ERROR to generate an
error message. Second, an implied-do loop can appear in
an initialization expression. So, gfortran is not handling
this correctly. Now, if one goes to expr.cc:gfc_match_init_expr,
gfortran matches the RHS expression, but gfc_reduce_init_expr()
fails to expand the array constructor.
--
Steve
