From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 388E73858CDB; Wed, 24 May 2023 20:28:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 388E73858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684960088; bh=rT46kSHp7YD0PFywQYoLCNsVvKrGm9HkX92xlekN0+4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wWUoEbICiEwc7Y8CWxOn8pgLhUtRO0RTZzOOxmBccYhVOwizmVFOp1lJrPzVAj8/t 6M+YX2bZ5wrpp0OLx4AaO/bnvCSnLweTU8NGndbRhc8v2e+ueP4wTYHxF+GVIOvQ8t Dw8KbDftys/e6AMrspvpUFrK2nUSXGaW9LTminqM= From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template Date: Wed, 24 May 2023 20:28:07 +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: 12.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109876 --- Comment #9 from Jason Merrill --- (In reply to Marek Polacek from comment #8) > > Instead, we should probably treat num as value-dependent even though it= actually isn't. >=20 > An attempt to implement that: >=20 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -27969,6 +27969,12 @@ value_dependent_expression_p (tree expression) > else if (TYPE_REF_P (TREE_TYPE (expression))) > /* FIXME cp_finish_decl doesn't fold reference initializers. */ > return true; > + else if (DECL_DECLARED_CONSTEXPR_P (expression) > + && TREE_STATIC (expression) I'd expect we could get a similar issue with non-static constexprs. > + && !DECL_NAMESPACE_SCOPE_P (expression) This seems an unnecessary optimization? > + && DECL_INITIAL (expression) Perhaps we also want to return true if DECL_INITIAL is null? > + && TREE_CODE (DECL_INITIAL (expression)) =3D=3D IMPLICIT_CONV_= EXPR) Maybe !TREE_CONSTANT?=