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 738A53858D38; Fri, 12 Apr 2024 09:59:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 738A53858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712915982;
	bh=RnTEruiOPRxzh3jWs1bFKwBuVPbCuLHYD24xc39LgPA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tqHwz+fjQmy/uXqU6Rh2EZISMaC8f3P3F6I5OiSDAO2kVXJUBdjPZcIQu+aQrIEmD
	 KMKWw9Mae8BGyhjnDYlEiyLxq8S1vKA+Orf0BblvmhKGw37NBz3zwN9+puGfxiY7VJ
	 5eWv5zjxOmXiDZgx4fywM3B05hTR/q+CDAyULVJs=
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, 12 Apr 2024 09:59:39 +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-NHERLUordn@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 #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually I had another look.
Jason said in the c++: fix in-charge parm in constexpr mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors there isn't actually a
need for an in-charge parameter in a destructor"
but the ICE is because the destructor is marked implicitly constexpr.
https://eel.is/c++draft/dcl.constexpr#3.2 says that a destructor of a class
with virtual bases is not constexpr-suitable, but we were actually implemen=
ting
this just for constructors, so clearly my fault from the
https://wg21.link/P0784R7 implementation.  That paper clearly added that
sentence in there and removed similar sentence just from the constructor ca=
se.
--- gcc/cp/constexpr.cc.jj      2024-04-09 09:29:04.708521907 +0200
+++ gcc/cp/constexpr.cc 2024-04-12 11:45:08.845476718 +0200
@@ -262,18 +262,15 @@ is_valid_constexpr_fn (tree fun, bool co
        inform (DECL_SOURCE_LOCATION (fun),
                "lambdas are implicitly %<constexpr%> only in C++17 and
later");
     }
-  else if (DECL_DESTRUCTOR_P (fun))
+  else if (DECL_DESTRUCTOR_P (fun) && cxx_dialect < cxx20)
     {
-      if (cxx_dialect < cxx20)
-       {
-         ret =3D false;
-         if (complain)
-           error_at (DECL_SOURCE_LOCATION (fun),
-                     "%<constexpr%> destructors only available"
-                     " with %<-std=3Dc++20%> or %<-std=3Dgnu++20%>");
-       }
+      ret =3D false;
+      if (complain)
+       error_at (DECL_SOURCE_LOCATION (fun),
+                 "%<constexpr%> destructors only available with "
+                 "%<-std=3Dc++20%> or %<-std=3Dgnu++20%>");
     }
-  else if (!DECL_CONSTRUCTOR_P (fun))
+  else if (!DECL_CONSTRUCTOR_P (fun) && !DECL_DESTRUCTOR_P (fun))
     {
       tree rettype =3D TREE_TYPE (TREE_TYPE (fun));
       if (!literal_type_p (rettype))
patch fixes the ICE too, just will need to add testcase coverage and see wh=
at
regresses in the testsuite...=