https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123663
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Created attachment 63477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63477&action=edit
pr123663-untested.patch
Issue is that nested '(maybe_)push_to_top_level' seems broken.
What happens here is when evaluating the concept we call 'push_to_top_level',
we see cfun is non-null, and so call 'push_function_context' which sets cfun to
NULL and sets a flag so that we remember to pop it later.
Then, when instantiating Foo's default constructor as part of the concept, we
call 'maybe_push_to_top_level'. Here we see that 'Foo' is function-local, so
'push_to_top == false', and we call 'push_function_context'. This allocates a
new cfun for some reason, and pushes that empty cfun.
Eventually we 'maybe_pop_from_top_level', and restore that newly allocated cfun
(instead of a NULL cfun), which means that when we start trying to build the
new-expression (which requires building a statement list) we try accessing the
(uninitialized) cfun's x_stmt_tree rather than the scope_chain's x_stmt_tree,
and so crash.
Remembering whether we had a cfun in local_state seems like the most reasonable
fix here that I can find, as in the attached (untested) patch.
