From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5EA8E385703F; Thu, 23 Feb 2023 18:39:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5EA8E385703F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677177541; bh=Kxd4YbUHiFAdfJmjVMURzW15vgRvmV1TFLPg+v70jEo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GOCDZZrVuzIIOdvhAono/+kCHSsBicAiX7krFRxF7Gh+y4o4AfHPlgoDOKlmrZAfH 6K9vll8lGl0NfYusVMINrVYWiQXMJwvYKvAwfR4/4/6/cKP0Ce0gAngvI7V0BlhKrO ggx+j7l+bE5zudgV28nwFyJRfsktADMNUBLtofuU= From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/69960] "initializer element is not constant" Date: Thu, 23 Feb 2023 18:38:58 +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: 5.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.0 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=3D69960 --- Comment #24 from joseph at codesourcery dot com --- On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote: > In this code=20 >=20 > static const int y =3D 1; > static int x =3D y; >=20 > y is not an integer constant expression, nor is it an integer constant in= the > meaning that ISO 9899 defines it. Correct, but irrelevant, since nothing in that code example is required by= =20 the standard to be an integer constant expression. > Therefore an initializer was given which is > not a constant expression. No, it's an "other form of constant expression" accepted by GCC. > "an implementation may accept other forms of constant expressions" does n= ot > mean that an implementation can throw out any constraints it pleases out = the > window. Correct. The Constraints on constant expressions say "Constant=20 expressions shall not contain assignment, increment, decrement,=20 function-call, or comma operators, except when they are contained within a= =20 subexpression that is not evaluated." and "Each constant expression shall=20 evaluate to a constant that is in the range of representable values for=20 its type.". The initializer is entirely consistent with those=20 Constraints, so it is within the bounds of what an implementation may=20 accept as an "other form of constant expression". Whereas it wouldn't be=20 valid for an implementation to accept f() as a constant expression=20 (contains a function call), for example. Note also that only violations of Syntax and Constraints require=20 diagnostics (and thus -pedantic doesn't claim to ensure diagnostics for=20 code that's not strictly conforming for some other reason than violating=20 Syntax or Constraints).=