From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id E8C573858D20 for ; Fri, 4 Feb 2022 08:29:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E8C573858D20 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 984F3147A; Fri, 4 Feb 2022 00:29:23 -0800 (PST) Received: from localhost (unknown [10.32.98.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A97573F73B; Fri, 4 Feb 2022 00:29:22 -0800 (PST) From: Richard Sandiford To: Alexey Neyman Mail-Followup-To: Alexey Neyman , gcc-help@gcc.gnu.org, richard.sandiford@arm.com Cc: gcc-help@gcc.gnu.org Subject: Re: -Wmissing-field-initializers false positive with compound literals References: Date: Fri, 04 Feb 2022 08:29:20 +0000 In-Reply-To: (Alexey Neyman's message of "Thu, 3 Feb 2022 12:03:46 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 08:29:25 -0000 Alexey Neyman writes: > Hi all, > > I've encountered a weird behavior of -Wmissing-field-initializers option= =20 > (which is a part of -Wextra) regarding structure initializers that=20 > contain compound literals as initializers for some of their fields.=20 > Reproduced with all GCC versions from 4.8.5 to 11.2. > > Consider the following test case: > > struct foo { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0const char *a1; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0const char * const *a2; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0void *a3; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0void *a4; > }; > > const char *aux[] =3D { "y", 0 }; > > struct foo a =3D { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a1 =3D "x", > #if defined(CASE1) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a2 =3D (const char * const []= ){ "y", 0 }, > #elif defined(CASE2) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a2 =3D aux, > #elif defined(CASE3) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a2 =3D 0, > #elif defined(CASE4) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* .a2 not initialized */ > #elif defined(CASE5) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a2 =3D (const char * const []= ){ "y", 0 }, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a3 =3D 0, > #endif > }; > > struct foo b =3D { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a2 =3D (const char * const []= ){ "y", 0 }, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.a1 =3D "x", > }; > > CASE1 gives a warning about 'a3' field being initialized, despite the=20 > manual stating that named field initializers should prevent this warning= =20 > from being generated. CASE2 initializes the field to point to an=20 > explicitly defined array, and it works with no warnings. CASE3 uses a=20 > constant as an initializer and also works without warnings. CASE5=20 > initializes the field 'a3' and produces no warnings about the next=20 > field, 'a4'. > > Reversing the order of the 'a1' and 'a2' initializers (as in the 'b'=20 > variable) also does not produce a warning. It seems that the warning is=20 > only produced if the last initialized field in a structure uses a=20 > compound literal. > > Looks like a bug to me; please confirm that I should file it into GCC's=20 > bugzilla. Yeah, I agree it's a bug. I think it's likely to be the same underlying issue as PR82283, so I've copied the example there (hope you don't mind). Thanks, Richard