https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is indeed the assert added in that patch.
When cp_fold_function is called on the _ZN12ConfiguratorD0Ev body which
contains
Configurator::~Configurator(this); call
Now, maybe_constant_value is called on this in:
/* Invoke maybe_constant_value for functions declared
constexpr and not called with AGGR_INIT_EXPRs.
TODO:
Do constexpr expansion of expressions where the call itself is not
constant, but the call followed by an INDIRECT_REF is. */
if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
&& !flag_no_inline)
{
mce_value manifestly_const_eval = mce_unknown;
if (flags & ff_mce_false)
/* Allow folding __builtin_is_constant_evaluated to false during
constexpr evaluation of this call. */
manifestly_const_eval = mce_false;
r = maybe_constant_value (x, /*decl=*/NULL_TREE,
manifestly_const_eval);
}
also on targets other than arm, but except on arm the maybe_constant_value ->
cxx_eval_outermost_constant_expr call returns very quickly, because the call
has VOID_TYPE_P and constexpr_dtor is false and the dtor isn't
DECL_IMMEDIATE_FUNCTION_P,
so it
/* Calls to immediate functions returning void need to be
evaluated. */
tree fndecl = cp_get_callee_fndecl_nofold (t);
if (fndecl == NULL_TREE || !DECL_IMMEDIATE_FUNCTION_P (fndecl))
return t;
The difference on arm is that the CALL_EXPR doesn't have VOID_TYPE_P type, but
pointer to the class, so it evaluates it and triggers the assertion.
Now, if all we want to do is get the same behavior on arm as on other targets,
perhaps
we could avoid doing that maybe_constant_value in cp_fold if DECL_DESTRUCTOR_P
(callee) or perhaps even DECL_CONSTRUCTOR_P (callee).
