From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id AB142385828C; Fri, 22 Mar 2024 15:50:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AB142385828C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1711122618;
	bh=QxyrjloWiWYiShZJoBbsYR2kEHHgRSB7Qh7oLaWgWTE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=yYn3iMpywYxgkpwCy9j6wMOePORCWN2dwyka/CGsdlbXkyd8AUMX9h9Itkf2VWc8d
	 VzV2oVh2qQ3WJeTfJchvvs98YjjvHGAnKi6TjTo/P1Xg0TvKftrKQPyunH5NR3Q31m
	 ouQZKm9lo5qqAWHzvHgU8mXcsiK82DrrNzZe30BQ=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/114426] [14 regression] ICE when building log4cxx on arm
 (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507
Date: Fri, 22 Mar 2024 15:50:17 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114426-4-9E3d9qgIYm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114426-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114426-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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 n=
ot
           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 =3D mce_unknown;
            if (flags & ff_mce_false)
              /* Allow folding __builtin_is_constant_evaluated to false dur=
ing
                 constexpr evaluation of this call.  */
              manifestly_const_eval =3D mce_false;
            r =3D maybe_constant_value (x, /*decl=3D*/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 =3D cp_get_callee_fndecl_nofold (t);
          if (fndecl =3D=3D 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 targe=
ts,
perhaps
we could avoid doing that maybe_constant_value in cp_fold if DECL_DESTRUCTO=
R_P
(callee) or perhaps even DECL_CONSTRUCTOR_P (callee).=