From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id DCE27384385C for ; Thu, 30 Jun 2022 14:24:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCE27384385C Received: by mail-ed1-x52c.google.com with SMTP id eq6so26750308edb.6 for ; Thu, 30 Jun 2022 07:24:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5B6qpRhQ+Jf81xbBwkH8KTwTC87m3hjQcEUWtygEq9k=; b=W6ZpSbee/6UM+MxPN3bwDH7otkroPi2ITPey08L0ukqJS7WaNaiSGKinHfdcAqawMl Eti/f5P6OlNpqqYGxnJc5+5R6JX7NUa7x8/+VSO5TQTMYLTgs3wT4BHhFIZK/j6uB/mq Gshc1nckodGYGerxX3mGijmKxAgvwwuyl8DbXRVJQSYQiXIq5dCmY6iDv6QWd5Rtthx4 bqmsZiHKRt3xanNoaZcp0Zl/rvk2bpEbCYoD7Y7ti2eZVIhfT/ROs1gBvA+vkBfJHkU4 jn2hHxhOin14qFNTuRrFjq5eQdUBsSLpfIOcKPf1YJ9ToFiuRXIno4ulb87wv9RZ1Eqi EfKQ== X-Gm-Message-State: AJIora+6e4CLS5MIj5SlNM5Vt4pytofjRhd8FPh+zPZuehZJDVJNnoTu qRoNYztTtEr7szEElJeVy4M= X-Google-Smtp-Source: AGRyM1tXhQEPhBpzGJctVeIvx5A7BeyvmxdIUmrKXCmle9ZID+2iKUQmGDGKTU1Zwvo/YBhtI1Y8fw== X-Received: by 2002:a05:6402:328f:b0:435:7f7a:7666 with SMTP id f15-20020a056402328f00b004357f7a7666mr11714883eda.168.1656599075705; Thu, 30 Jun 2022 07:24:35 -0700 (PDT) Received: from smtpclient.apple (dynamic-095-117-120-011.95.117.pool.telefonica.de. [95.117.120.11]) by smtp.gmail.com with ESMTPSA id a27-20020a170906275b00b00722e57fa051sm9097334ejd.90.2022.06.30.07.24.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jun 2022 07:24:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size Date: Thu, 30 Jun 2022 16:24:34 +0200 Message-Id: <6CB6B076-0635-4DE8-861E-F8EBC0B696B4@gmail.com> References: Cc: Martin Sebor , Jakub Jelinek , gcc-patches Paul A Clarke via , kees Cook In-Reply-To: To: Qing Zhao X-Mailer: iPhone Mail (19F77) X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 14:24:38 -0000 > Am 30.06.2022 um 16:08 schrieb Qing Zhao via Gcc-patches : >=20 > =EF=BB=BF >=20 >> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote: >>=20 >> On 6/28/22 13:01, Qing Zhao wrote: >>>> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote: >>>>=20 >>>> On Tue, Jun 28, 2022 at 06:29:01PM +0000, Qing Zhao wrote: >>>>>=20 >>>>>=20 >>>>>> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek wrote: >>>>>>=20 >>>>>>> On Tue, Jun 28, 2022 at 06:15:58PM +0000, Qing Zhao wrote: >>>>>>>>> Because the flag just tells whether some array shouldn't be treate= d as (poor man's) >>>>>>>>> flexible array member. We still need to find out if some FIELD_DE= CL is to >>>>>>>>> be treated like a flexible array member, which is a minority of >>>>>>>>> COMPONENT_REFs. >>>>>>>>> struct S { int a; char b[0]; int c; } s; >>>>>>>>> struct T { int d; char e[]; }; >>>>>>>>> struct U { int f; struct T g; int h; } u; >>>>>>>>> Neither s.b nor u.g.e is to be treated like flexible array member,= >>>>>>>>> no matter what -fstrict-flex-array=3D option is used. >>>>>>>>=20 >>>>>>>> Then, to resolve this issue, we might need a opposite flag DECL_IS= _FLEXARRAY in FIELD_DECL? >>>>>>>>=20 >>>>>>>> The default is FALSE for all FIELD_DECL. >>>>>>>=20 >>>>>>> Doesn't matter whether it is positive or negative, you still need to= analyze >>>>>>> it. See the above example. If you have struct T t; and test t.e, t= hen it >>>>>>> is flexarray. But u.g.e is not, even when the COMPONENT_REF refers t= o the >>>>>>> same FIELD_DECL. In the t.e case e is the very last field, in the l= atter >>>>>>> case u.g.e is the last field in struct T, but struct U has the h fie= ld after >>>>>>=20 >>>>>> So, do you mean that the current FE analysis will not be able to deci= de whether a specific array field is at the end of the enclosing structure? >>>>>> Only the middle end can decide this ? >>>>>=20 >>>>> Well, anything that analyzes it, can be in the FE or middle-end, but t= here >>>>> is no place to store it for later. >>> Then I am a little confused: >>> If the FE can decide wether an array field is at the end of the enclosin= g structure, then combined with whether it=E2=80=99s a [0], [1] or [], and w= hich level of -fstrict-flex-array, >>> The FE should be able to decide whether this array field is a flexible a= rray member or not, then set the flag DECL_IS_FLEXARRAY (or DECL_NOT_FLEXARR= AY). >>> The new flag is the place to store such info, right? >>> Do I miss anything here? >>=20 >> I think the problem is that there is just one FIELD_DECL for member >> M of a given type T but there can be more than one instance of that >> member, one in each struct that has a subobject of T as its own >> member. Whether M is or isn't a (valid) flexible array member >> varies between the two instances. >=20 > Okay, I see.=20 > A FIELD_DECL might be shared by multiple structure or unions, and whether=20= > it=E2=80=99s a flexible array member varies between different enclosing st= ructures or unions. > Therefore FIELD_DECL cannot carry the flexible array member information ac= curately.=20 No, that=E2=80=99s not true. A FIELD_DELC is only shared for cv variants of= a structure. > Then, how about encoding the flexible array member information into the en= closing structure or union?=20 >=20 >=20 > Another thing is: All this complexity is caused by GNU extension which pe= rmits the flexible array=20 > member not at the end of the struct. (As I mentioned in a previous email, I= listed here again) >=20 > For example the following two examples: >=20 > 1. [opc@qinzhao-ol8u3-x86 trailing_array]$ cat t1.c > struct AX > { > int n; > short ax[]; > int m; > }; >=20 > void warn_ax_local (struct AX *p) > { > p->ax[2] =3D 0; =20 > } >=20 > 2. [opc@qinzhao-ol8u3-x86 trailing_array]$ cat t2.c > struct AX > { > int n; > short ax[]; > }; >=20 > struct UX > { > struct AX b; > int m; > }; >=20 > void warn_ax_local (struct AX *p, struct UX *q) > { > p->ax[2] =3D 0; =20 > q->b.ax[2] =3D 0; > } >=20 > [opc@qinzhao-ol8u3-x86 trailing_array]$ gcc -O2 -Wall t1.c -S > t4.c:4:9: error: flexible array member not at end of struct > 4 | short ax[]; >=20 > [opc@qinzhao-ol8u3-x86 trailing_array]$ gcc -O2 -Wall t2.c -S >=20 > It=E2=80=99s clear to see that in the above t1.c, GCC reports error when= the flexible array member is Not at the end of the structure (AX) that imm= ediately enclosing the field. > However, for t2.c, when the flexible array member is Not at the end of the= structure that does not immediately enclosing it (UX), then it=E2=80=99s ac= cepted. =20 >=20 > I am very confused about t2.c, is the struct UX a correct declaration?=20 >=20 > Thanks. >=20 > Qing >=20 >>=20 >> Martin >=20