From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 53BF43858D39 for ; Wed, 8 Feb 2023 19:09:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53BF43858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="100085052" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 08 Feb 2023 11:09:32 -0800 IronPort-SDR: Y0MHphl627e22r5OjM3EXdR24AuilQJBrjpEkDkm6ayqcUYKmsWtYX3eJZHy55W0Nd2Ravyhfw OcdvgkDQKCnhdq+lR7eLErY0IxzMaTKi7rDdtv2z5WJbC/SHdQYtbxTrEmF/js30ImX9RyNb9p APOPM8xzZOrs18gEbzJB9e6s38po+0nD9ia5gEV2TJMqmelXTIq1maMO2z7+fki8rX+OuWJIrz tgcrLnAookqw65eiGGSAXjyocnQww9wzGVXf46iKWRLyrxJcZGEJWXFy2+YmUY1aEEG2ENdDEf uhM= Date: Wed, 8 Feb 2023 19:09:27 +0000 From: Joseph Myers To: Qing Zhao CC: richard Biener , "gcc-patches@gcc.gnu.org" , "siddhesh@gotplt.org" , "keescook@chromium.org" Subject: Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] In-Reply-To: <2AB95191-B5D9-41AC-916A-C57ED20DF55E@oracle.com> Message-ID: <17bc7992-23b6-63dc-3a3a-1be016d3bbb@codesourcery.com> References: <20230131141140.3610133-1-qing.zhao@oracle.com> <20230131141140.3610133-2-qing.zhao@oracle.com> <812910BC-870E-4432-870D-538024F1A510@oracle.com> <3B30CFBF-5004-41A4-940D-1F23C010403B@oracle.com> <4E515AA5-2069-497E-A301-EC8ED744E780@oracle.com> <367EBE15-1675-4D29-A9C2-A4A57FA4DB62@oracle.com> <2184ee29-9a36-e85-11c5-81c47aa22055@codesourcery.com> <91678405-D50E-405A-98FB-F3BA6888577E@oracle.com> <2AB95191-B5D9-41AC-916A-C57ED20DF55E@oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-908716036-1675883367=:29886" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3108.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: ---1152306461-908716036-1675883367=:29886 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote: > But I noticed that “flexible_array_type_p” later was moved from FE to > middle-end and put into tree.cc, tree.h as a general utility routine, and to > > /* Determine whether TYPE is a structure with a flexible array member, > or a union containing such a structure (possibly recursively). */ > > However, since this routine does not cover the cases when the structure > with flexible array member was recursively embedded into structures, (which we > agreed that it should be considered as a flexible sized type). > > Therefore, I feel that It might not be proper to include this routine in middle end > (and actually no other places In middle end use this routine so far). I think we've established that diagnostics and at least some middle-end purposes need different conditions. Diagnostics for nesting a structure with a flexible array member inside another structure should only count [] as a flexible array member, whereas permitting flexible array uses in the middle end should allow [0] and [1] under some circumstances (depending on command-line options). > But: > > struct flex0 { int n; int data[0]; }; > struct out_flex_end0 { int m; struct flex0 flex_data; }; > struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; }; > > In the above, only “flex0” is flexible sized type by default. > But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized type by default? It would be OK (and I'm not saying here that this is necessarily desirable), since that's at the end of another structure rather than in the middle, to consider them flexible for the purposes of code generation. What must be avoided is -pedantic diagnostics for struct flex1 { int n; int data[1]; }; struct out_flex_end1 { int m; struct flex1 flex_data; }; regardless of whether considered flexible or not, since that's clearly valid in standard C. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-908716036-1675883367=:29886--