[Bug fortran/98458] ICE in gfc_conv_array_initializer due to array expressions within implied do-loop

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Dec 30, 2020 at 01:40:22PM +0000, pault at gcc dot gnu.org wrote:
> --- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
> (In reply to Steve Kargl from comment #6)
> 
> Hi Steve,
> 
> I didn't check for any new postings when I attached my version
> of the patch.  Apologies for treading on your toes.... again :-)

You didn't step on any toes.  I think your original patch is
better than mine, because it applies to any place where
is_constant_array_expr() is called.  I suspect your patch is
probably better placed someplace in gfc_simplify_expr(), but
that is for another day.

> > My proposed patch fixes the issue in one spot.  Paul's
> > patch fixes potentially many spots.  Unfortunately, the
> > handling of implied do-loops is done in an ad hoc fashion,
> > and is complicated by the potential problem of exhausting
> > the stack.
> 
> I like your use of gfc_reduce_init_expr since it also does
> a type check.  Note though that it resets gfc_reduce_init_expr
> and so it needs to be set once again after the call.

Ah, good point about resetting gfc_reduce_init_expr flag.

When debugging the problem, I found that

source=[ [1,2], [2,3], [3,4] ]

so the implied do-loop was expanded, but the array was not
simplified to [1, 2, 2, 3, 3, 4].  This was causing 
gfc_simplify_reshape to return NULL. 

> I had totally forgotten about the 'fatal' flag needing to be
> set in the call to gfc_expand_constructor to avoid stack
> exhaustion. I had to rediscover it experimentally.

implied do-loops in PARAMETER statements have been a problem
for a long time.  I only remember the problem with exhausting
the stack, because I chose flag_max_array_constructor = 65535.

> A combined patch is being regtested now.

Thanks.