From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B7C103857BA4; Fri, 24 Feb 2023 07:52:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B7C103857BA4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677225154; bh=9Wo5LiFfcCfl5Z7ci9icF+sp32JWQfboeQOGcDNARHA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nspF4ICh3vecVNzr7hFJeIG2Z6Ri5YLcVkcucvnGGYjxuBJdzKWbogRAp23FFa0I1 n2JMK3T2EksWZL7LpeoWfbzfwwE196QTfQBjA7NUuUr7kRNyBPUyu0ixgDJ0avnag+ npFlNQbF69+fsGzAqVqGJ5GucReTcVVh7VnORoiQ= From: "daniel.lundin.mail at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/69960] "initializer element is not constant" Date: Fri, 24 Feb 2023 07:52:33 +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: daniel.lundin.mail at gmail 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 #25 from Daniel Lundin --- (In reply to joseph@codesourcery.com from comment #24) > On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wro= te: >=20 Regardless of how one chose to read that part of the standard, fact remains that this part of the standard has not changed since C89 but still gcc beha= ves wildly different depending on version. This makes it impossible to port strictly conforming programs between different gcc versions, because then you'll either get a diagnostic that you (arguably) shouldn't be getting, or= you will not get a diagnostic where you (arguably) should be expecting one.=20 This makes gcc a hazard in my case. My choices are to forbid newer versions= or to port to a different compiler. In case -pedantic would still result in a diagnostic past version 8 then that would make gcc behave consistently acro= ss versions and that would solve the problem. As was already mentioned previou= sly in this thread, before this change was implemented with that remark ignored. Additionally there is bug #2 where (uint32_t)&function_pointer does not giv= e a diagnostic in case the pointer is 32 bit, which is non-conforming behavior = for constant expressions. I should perhaps open a separate bug report about that since I'm not sure if it's related to this one.=