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.
