From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 096743858284; Wed, 22 Feb 2023 17:00:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 096743858284 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677085228; bh=8IiifiY2n5ZNuhN8DIt/0gLuXeub5E67IeYFvhL9tJI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vQn8YMVs+e7NI6fGZoxRqzSewQJ/HbNiI25tDIECP2YxeGBIXDD5yzCpeNucC+CZH Y7xFmhUsb79zS6C0Bagp598dnERi4UM0qsceHV2L3o1FExGoaw0U/FQqmYPqzr8/xf ZSHeiJj1weEuwjJ06nl7Pg1t/9m+ecmUWwf7mauM= From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/69960] "initializer element is not constant" Date: Wed, 22 Feb 2023 17:00:25 +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 #21 from joseph at codesourcery dot com --- On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote: > First of all, it is questionable if gcc is still conforming after the cha= nge > discussed here and implemented as per gcc 8.0. Yes "an implementation may > accept other forms of constant expressions" but that doesn't mean that a > compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the defi= nition > of an integer constant expression. So this ought to explicitly be a compi= ler > extension and we ought to have a way to reliably compile strictly conform= ing > programs with gcc without constraint violations silently getting ignored.= =20 "integer constant expression" does not mean the same thing as "constant=20 expression of integer type". If you use this expression in a context=20 requiring an integer constant expression (case label, bit-field width,=20 array designator in initializer, enum value, array size at file scope,=20 constexpr initializer for object of integer type, etc.), it's properly=20 rejected as required; in contexts where both integer constant expressions=20 and other expressions are valid but with different semantics (e.g.=20 determining whether something is a null pointer constant, determining=20 whether an array is a VLA in a context where both VLA and non-VLA arrays=20 are valid), again it's treated as non-constant.=