On Fri, 15 Mar 2024, Marek Polacek wrote:
> On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote:
> > On Tue, 5 Mar 2024, Marek Polacek wrote:
> >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > Here we ICE because we call register_local_specialization while
> > > local_specializations is null, so
> > >
> > > local_specializations->put ();
> > >
> > > crashes on null this. It's null since maybe_instantiate_noexcept calls
> > > push_to_top_level which creates a new scope. Normally, I would have
> > > guessed that we need a new local_specialization_stack. But here we're
> > > dealing with an operand of a noexcept, which is an unevaluated operand,
> > > and those aren't registered in the hash map. maybe_instantiate_noexcept
> > > wasn't signalling that it's substituting an unevaluated operand though.
> >
> > It thought it was noexcept-exprs rather than noexcept-specs that are
> > unevaluated contexts?
>
> Yes, sigh. It would have to be noexcept(noexcept(x)). I was looking at
> cp_parser_unary_expression/RID_NOEXCEPT but that's a noexcept-expr. So
> what can we do here, set a new local_specialization_stack? That wasn't
> that straightforward when I tried. Or maybe just
Maybe we can avoid doing push_to_top_level (which clears
local_specializations) from maybe_instantiate_noexcept if
current_function_decl == fn?
Relatedly I wonder if we can avoid calling regenerate_decl_from_template
for local class member functions since they can't be redeclared?
>
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -15649,7 +15649,7 @@ tsubst_decl (tree t, tree args, tsubst_flags_t
> complain,
> {
> if (DECL_LANG_SPECIFIC (r))
> DECL_TEMPLATE_INFO (r) = NULL_TREE;
> - if (!cp_unevaluated_operand)
> + if (!cp_unevaluated_operand && local_specializations)
> register_local_specialization (r, t);
> }
>
> ?
>
>
