Re: typespec in forall and implied-do

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

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