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 E1C8A3858D20 for ; Wed, 8 Feb 2023 20:51:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E1C8A3858D20 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="100095379" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 08 Feb 2023 12:51:29 -0800 IronPort-SDR: inow+eBee4xdOfdDABBfN/Ri5TtwuzD74IJ20hXB/6LUfYdA7e1mgQWImgVA7QcBHT/DyV+dfI x+ThX0nTg14J+jR8us0+WwZ5drcoTIqy36GS4OoQjyoxGljtUor7skz/CCCpmrDXqwRtmChXCZ v31vDZvHgqYmNfY4lE5o3KuoZZ6j+WpK9xoBCLsotHhOs5RZSURt90BFT1fZ0FrM8KV0L64Dp4 SqzoewvnScXmHMa4T1HJvw97MrQYGWW3VvsoP1oXlH8zhVXoLIXofkts3236QBvOI1GlJMoX/Z zh8= Date: Wed, 8 Feb 2023 20:51:25 +0000 From: Joseph Myers To: Siddhesh Poyarekar CC: Qing Zhao , richard Biener , "gcc-patches@gcc.gnu.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: Message-ID: <86a4c99-bd6e-9f9f-12bd-3d306cfe37f@codesourcery.com> References: <20230131141140.3610133-1-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> <17bc7992-23b6-63dc-3a3a-1be016d3bbb@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) 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: On Wed, 8 Feb 2023, Siddhesh Poyarekar wrote: > On 2023-02-08 14:09, Joseph Myers wrote: > > 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. > > > > Are you sure about "regardless of whether considered flexible or not", since > ISTM the validity of the above in standard C is limited to when it's > considered a non-flexible array. So with -pedantic it shouldn't warn, but it > also then shouldn't consider it a flexible array. > > In other words, perhaps it makes sense to imply -fstrict-flex-arrays with > -pedantic? There should be no code generation effects from -pedantic. -- Joseph S. Myers joseph@codesourcery.com