From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 308BA3858D3C; Wed, 24 May 2023 18:30:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 308BA3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1684953049; bh=RFc4dRuWOVM2P562x2cmuBPbz5tQTl5fpR4Ofv1vVdQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IBqsSzDYEKdl0UeqZgd/EfOj3iBxQ4o5zOHoq1x3Oxc91GGcAzL6iqm3Fq/Oz5gU1 Q/X6AypFVqIpeUdi5RY0X3pAp/1SX6v4Iwsw5t8aklw4d7uXNFtMHedlOPx2tVAAMW Cg2dmZtl4IjJBNtV8HH+izsr3nvmKHXXCCbcLeCQ= From: "pascal_cuoq at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3}; Date: Wed, 24 May 2023 18:30:48 +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: X-Bugzilla-Severity: trivial X-Bugzilla-Who: pascal_cuoq at hotmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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=3D109956 --- Comment #3 from Pascal Cuoq --- @Andrew Pinski You don't even need to invoke the fact that this is an extension. GCC could reserve 17 bytes for each variable i of type =E2=80=9Cint=E2=80=9D, and as = long as =E2=80=9Csizeof i=E2=80=9D continued to evaluate to 4 (4 being the value of =E2=80=9Csizeof(int)=E2=80= =9D for x86), no-one would be able to claim that GCC is not generating =E2=80=9Ccorrect=E2=80=9D= assembly code. This ticket is pointing out that the current behavior for initialized FAMs = is suboptimal for programs that rely on the GCC extension, just like it would = be suboptimal to reserve 17 bytes for each =E2=80=9Cint=E2=80=9D variable for = standard C programs (and I would open a ticket for it if I noticed such a behavior). It's not breaking anything and it may be inconvenient to change, and as a ticket that does not affect correctness, it can be ignored indefinitely. It= 's just a suggestion for smaller binaries that might also end up marginally fa= ster as a result. @Martin Uecker Considering how casually phrased the description of FAMs was in C99 and remained in later standards (see https://stackoverflow.com/q/73497572/139746 for me trying to make sense of some of the relevant words), I doubt that the standard has anything to say about the compiler extension being discussed. = But if you have convincing arguments, you could spend a few minutes filing a bug against Clang to tell them that they are making the binaries they generate = too small and efficient.=