From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C2FB9386CE4B for ; Thu, 30 Jun 2022 17:03:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2FB9386CE4B Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-516-wsAmakn_OUmn1TFinb-A5g-1; Thu, 30 Jun 2022 13:03:44 -0400 X-MC-Unique: wsAmakn_OUmn1TFinb-A5g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A5656811E7A; Thu, 30 Jun 2022 17:03:43 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 61D362166B26; Thu, 30 Jun 2022 17:03:43 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 25UH3eMM4008596 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 30 Jun 2022 19:03:40 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 25UH3dp94008595; Thu, 30 Jun 2022 19:03:39 +0200 Date: Thu, 30 Jun 2022 19:03:39 +0200 From: Jakub Jelinek To: Qing Zhao Cc: Richard Biener , Martin Sebor , gcc-patches Paul A Clarke via , kees Cook Subject: Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size Message-ID: Reply-To: Jakub Jelinek References: <6CB6B076-0635-4DE8-861E-F8EBC0B696B4@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 17:03:50 -0000 On Thu, Jun 30, 2022 at 03:31:00PM +0000, Qing Zhao wrote: > > No, that’s not true. A FIELD_DELC is only shared for cv variants of a structure. > > Sorry for my dump questions: > > 1. What do you mean by “cv variants” of a structure? const/volatile qualified variants. So > 2. For the following example: > > struct AX { int n; short ax[];}; struct AX, const struct AX, volatile const struct AX etc. types will share the FIELD_DECLs. > struct UX {struct AX b; int m;}; > > Are there two different FIELD_DECLs in the IR, one for AX.ax, the other one is for UX.b.ax? No, there are just n and ax FIELD_DECLs with DECL_CONTEXT of struct AX and b and m FIELD_DECLs with DECL_CONTEXT of struct UX. But, what is important is that when some FIELD_DECL is last in some structure and has array type, it doesn't mean it should have an unconstrained length. In the above case, when struct AX is is followed by some other member, it acts as a strict short ax[0]; field (even when that is an exception), one can tak address of &UX.b.ax[0], but can't dereference that, or &UX.b.ax[1]. I believe pedantically flexible array members in such cases don't necessarily mean zero length array, could be longer, e.g. for the usual x86_64 alignments struct BX { long long n; short o; short ax[]; }; struct VX { struct BX b; int m; }; I think it acts as short ax[3]; because the padding at the end of struct BX is so long that 3 short elements fit in there. While if one uses struct BX bx = { 1LL, 2, { 3, 4, 5, 6, 7, 8, 9, 10 } }; (a GNU extension), then it acts as short ax[11]; - the initializer is 8 elements and after short ax[8]; is padding for another 3 full elemenets. And of course: struct BX *p = malloc (offsetof (struct BX, ax) + n * sizeof (short)); means short ax[n]. Whether struct WX { struct BX b; }; struct WX *p = malloc (offsetof (struct WX, b.ax) + n * sizeof (short)); is pedantically acting as short ax[n]; is unclear to me, but we are generally allowing that and people expect it. Though, on the GCC side, I think we are only treating like flexible arrays what is really at the end of structs, not followed by other members. Jakub