Message ID | FF9C7E0B-5DF6-4FC2-B3C2-29F3CBCBE147@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9D6F13858436 for <patchwork@sourceware.org>; Tue, 20 Dec 2022 16:17:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D6F13858436 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671553024; bh=wH8BLtFUbXIlJ18nURP4dvk1sfF2Oza1i/5LEF7JNzI=; h=To:CC:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=uDNuLsbNLZLJBjLAqaNh39SU+Wb63C9q1eJw7er9ZOQCFivixymESdnaG1Oe9iDWV k6EiRQD0KU2MHAWy0NVgaxRrD6Nh63ACurpRNzOw9jEoYyr8JNSGVDLVN5pVGaVyC6 x87agIsvq7TyAY2IZbz2O/cxRdSC6sd3PSOOaiRo= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 376993857C43 for <gcc-patches@gcc.gnu.org>; Tue, 20 Dec 2022 16:16:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 376993857C43 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BKFwncL015036; Tue, 20 Dec 2022 16:16:33 GMT Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3mh6tn63xe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Dec 2022 16:16:33 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 2BKFT27Q009703; Tue, 20 Dec 2022 16:16:32 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2108.outbound.protection.outlook.com [104.47.58.108]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3mh47bm32v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Dec 2022 16:16:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JGvL1n+Y2OfJre+HgajvpI1WRHgjrEY7hgdl8WTDdXqtLF4pRsMMJzf26w0jfWrWQpAlVaX1NhOr3IonbLPNS7ktxWy2W4i+6Q0aH08DtEVnU9Zl0Kxw+Orqw0SPfP61zZq2wqT8iA8nX2/L3pYL6l9iEYrNTlTz97VU1r68by/YmJAf9Fg7LKPI0D9OFuzhIU5q3XKYICiORlO4R70zehSBONfpX4ThlkX3mqwg/T/iejkvYV37p7ySY4yUTiE8+sgrXxq3+fOqILtjITG/aSL8vkgC0C8LH6/8tzKnJfdfC5rquy/cOsKj2Cxm0g7AkC+yIwfVl9Pj5AV8f8MkTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wH8BLtFUbXIlJ18nURP4dvk1sfF2Oza1i/5LEF7JNzI=; b=Jl1wiGWqJ93J6bjq/lJ7KiWr4oTguGUDachyUfsHsrcL9lc2oxQGP4zf4/4qe9BGXjmGXH+ISJFBv72Dic2jK819nUC3C7AcNMtwgMjVmZ4cuO5cRzzu7nmmOYEuYVZVo0MChgMsd2GFIWX81aX7/+bX5Cbf/YMFniZf0kzVW23DaNqRDw58UNs0i3C9qIvX51pCxTcPGWD4ZQX5p6MInuF61OX/jqgtwRstQvr9Tvvz2IS9orkoeEv3v+9H5qNaznZlLIgiWV+OT1rzdHdC+xSquYlcxkS6i002/a2T38lH5viO7Frnt5K6m3WY1EcHaSaWnqeeYNPrq8G0fJzl2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from CH2PR10MB4344.namprd10.prod.outlook.com (2603:10b6:610:af::19) by IA1PR10MB7335.namprd10.prod.outlook.com (2603:10b6:208:3d8::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.16; Tue, 20 Dec 2022 16:16:30 +0000 Received: from CH2PR10MB4344.namprd10.prod.outlook.com ([fe80::9423:79b3:c0dc:1113]) by CH2PR10MB4344.namprd10.prod.outlook.com ([fe80::9423:79b3:c0dc:1113%9]) with mapi id 15.20.5924.016; Tue, 20 Dec 2022 16:16:30 +0000 To: richard Biener <rguenther@suse.de> CC: gcc Patches <gcc-patches@gcc.gnu.org> Subject: gcc-13/changes.html: Mention -fstrict-flex-arrays and its impact Thread-Topic: gcc-13/changes.html: Mention -fstrict-flex-arrays and its impact Thread-Index: AQHZFI5rUtiNDK6HIkGums2aiQ+ASQ== Date: Tue, 20 Dec 2022 16:16:30 +0000 Message-ID: <FF9C7E0B-5DF6-4FC2-B3C2-29F3CBCBE147@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3696.120.41.1.1) x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH2PR10MB4344:EE_|IA1PR10MB7335:EE_ x-ms-office365-filtering-correlation-id: 395147a2-43ac-407b-684f-08dae2a58de7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MZQtliTevlfLBQpX79mCphSwU+ELJ955+7yW9EwIFR4RSz9/xjyCBH7KzCyKgxmVdiHl9LhEuJRf8uNBx8bXf7X6qC5eExegYohmEY8O0oup56nQJzdmRbYPj1DWV85dj+2MDqRA9kGgMYVLsuZFh5LZ+ZzG9flGDtxrJvckx0buXWedGA9ApE3FRzIaKEhF3nWfsoxADHgbWv8gUD4KFnvrCTYZwFxnvWp325Gjft90ApP8c5dPcEAV0m0xFx1ro507q/QXM5lVg16VEVR4UX19NeQFy/hbCMXCCHG8lJqfT1n3SD85D/BrECzfWIKFKynH/8S4l0lJ24AucpZ+hsRUmW18lSDEE77DL28H70lFlD4ombg7D/H8pB6za5KcpHmTfmhb+zWltmc+Q+QPVbgaNvHRomqlXhcfQfI7Le1zbMsVsa14Zg+0+hbJzE81aT1XWLtaX+C1S0/X53OdsDjtygC1/o8o5pSZDFzIHHkY/LbYOCkZNNFhe+MO2CwQx313RnKSsO8xoFMX/L762dlzSTt66rf0me3n9aASAvGCbEXfC68AMX57SVCj3y3NmHCzcs7kfHZuHL542TsOyKEAUh7PO8qf7+zzjzMah2Hk2DVRFaOSoM7BZybL2KHCdNn4P2ODyXIr588I+9ndGWlyDic54q4F9icPl5WO7jDhNtmF5m9qMiFl8n35/sfvT/Axmv/SjEuDMo0O910Swb9RL50HCsVQe4Sp7BL3i68= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR10MB4344.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(376002)(39860400002)(346002)(366004)(396003)(136003)(451199015)(36756003)(6916009)(2906002)(38070700005)(316002)(44832011)(6486002)(83380400001)(478600001)(53546011)(6506007)(86362001)(2616005)(33656002)(6512007)(71200400001)(186003)(26005)(8936002)(122000001)(38100700002)(41300700001)(76116006)(66946007)(5660300002)(4326008)(64756008)(66476007)(91956017)(66446008)(66556008)(8676002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: pDgAK2xbewH3IUdRio2ga6+5kL6HI/05N2uNJsPsKcMewlNxU9NK1kZHwe7ZxUk+C55Fne2Lf1kOHsSuDqtF3HMJAsxVSAWjrPwrOgDgKsmAlnW7agGCsWbqMQa3dDCmP0fUQCZ8HclxJgap6ioQgU0K/8lm9/6gWJnimBlEwsEls8UAXTwQx97CN/DKYTAt9wByMVzd01UYK4cxD7sCX/4/F/66QpgSNpRA+0rlkpm2skVluocHw/0nQqbnXOD7gDimbCtTtXAmTspHvpP8BS54dKgwdVHcCbxXS45nmU/ztOQbe8BXxEy7xtZkFgr6oRzwxZfybBf8Ne6RKtm3PTKB0P2U4p5jxWD9OgRNJOOlXpombKKOPWdHCocIMKQKXYFcvmgvEBfyzEJv0c7ez+NiI3ZFVEOW5kg1mR69HAkdsuEJbN76+FxA2x10iwUBmdN1JaoB3dFdDfvuaa8KBCZgE+O9l+gVdCA2TAxISwprLVUMBkxqehhtaYVs6hrFfYb6blLWPI3cRQisdc0Bx7Q6TuxEbdH5vVCkAjCKWkfNVKcNAxzX5T7hh4GddqMfsAZPodxP7C0FxN+DjtVOv4ZsHJhBLBIl01d8v2NS/8u51myy3Aflio3secJxA3wiPH/mYncSDyhufcMtUJh1SK71sGiBVEBGVnvP7EdCg/7gVnW7JDRD9ZAWq0qmd9gwnNDAovO6QT1F+ldDgL5ZoMZdmU0C6ct0SQ103Xt+5tOAZGpHP5SGUqqDfi+iB9pzk6AgS8mxI+HABhrxJ1W50uf96cQjG8prA1dZSZ85o3xz4QvGWFkvwCGMrXW5juf5G8cG6Fry9yz2veUGT9N6Jknc12KnNNIr82qp84k9D0NM1lPJI12SZ8DkAKAm/nOBV7H10j1fK0HJiwGvqhunck8oN0K3DyzV5gaGPgkjZwCwHbHmN0Yfz8VNS+f4AtIkoQu/k813GpKePGO9bXC/UewwKF1qep0D1kgl2Tpx/8YPdC4dfGdWAB/V8Fnlfs40JklavIqLfJAZAhJH37MLhGtY1ke1Fj+9jXvBttSUjTKIh0XnF/llVZ8kKK5jSPsvKFcKYDa8cxJbH2yI0OVbZ5p40fKMlNSwK44GSqrkH4czk1gOeuq7aamO1wBNitCRSgAixsXUSoAtona6ce2c7F2PL88YX1LCBceUYSPG3RCe76YJyIZyrETp53wjzVlObuEbPaj7s7YJCUWcjnX6cudGpK6FweaVANKHHqi1iNsirUCqXsY/Xi6dZvJylM1ZOvrx2d04Iqnod4cs48g/I3ljVHpwQmwxXU7qmk/NdJ99GpFSEeadkbgs08vBvCIZk5yz1kNNgR7QWrtCKz7vLrZbQBT9fn8UCJpd2eKG6yrxxaULQXtfNGYPq+ibD/cgvxkGZBBI/ugzBjdXlfrlCsJNE98OKiYDS0DADJB+yt+DYmR6bMWuKmTM3NF/4VV1y6ZqPY2lbI062kPSmv4S7fKoT0b1LbqoMsm30Sgaxl4GT6AY4XLnxpt7lU1owABaXQmvhhKpNkgcnICJdyjk1IWw8sWYotaBq9eOupJQkEhvq+0jheoIqorRZpdG2q+u1Gzlt07w5iAEEBRvqDyu5w== Content-Type: text/plain; charset="us-ascii" Content-ID: <C4974267A8F7C443883063249C008977@namprd10.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4344.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 395147a2-43ac-407b-684f-08dae2a58de7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2022 16:16:30.3955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X+X605/NgG6THc60IHkq7rLlvRIj/w7ENEKNu9gfH6BziCxtnLmi0iIsH9ZUq2UY/PDsRAeHHvenu5e9QZQWkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB7335 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-20_06,2022-12-20_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212200135 X-Proofpoint-ORIG-GUID: wrtJwQDnNw9nOLjob2Ka-WRfokos5MTB X-Proofpoint-GUID: wrtJwQDnNw9nOLjob2Ka-WRfokos5MTB X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Qing Zhao <qing.zhao@oracle.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
gcc-13/changes.html: Mention -fstrict-flex-arrays and its impact
|
|
Commit Message
Qing Zhao
Dec. 20, 2022, 4:16 p.m. UTC
Hi,
This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
Let me know if you have any comment or suggestions.
Thanks.
Qing.
=======================================
From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
From: Qing Zhao <qing.zhao@oracle.com>
Date: Tue, 20 Dec 2022 16:13:04 +0000
Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
---
htdocs/gcc-13/changes.html | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Comments
On Tue, 20 Dec 2022, Qing Zhao wrote: > Hi, > > This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. > > Let me know if you have any comment or suggestions. Some copy editing below > Thanks. > > Qing. > > ======================================= > From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 > From: Qing Zhao <qing.zhao@oracle.com> > Date: Tue, 20 Dec 2022 16:13:04 +0000 > Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. > > --- > htdocs/gcc-13/changes.html | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html > index 689178f9..47b3d40f 100644 > --- a/htdocs/gcc-13/changes.html > +++ b/htdocs/gcc-13/changes.html > @@ -39,6 +39,10 @@ a work-in-progress.</p> > <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed > and the option is ignored right now.</li> > <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> > + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds > + accesses to trailing struct members of one-element array type anymore. Please > + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat > + trailing arrays of structures as flexible array members. </li> "Instead it diagnoses accesses to trailing arrays according to <code>-fstrict-flex-arrays</code>." > </ul> > > > @@ -409,6 +413,17 @@ a work-in-progress.</p> > <h2>Other significant improvements</h2> > > <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> > +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> > + > +<ul> > + <li>GCC can now control when to treat the trailing array of a structure as a > + flexible array member for the purpose of accessing the elements of such > + an array. By default, all trailing arrays of structures are treated as all trailing arrays in aggregates are treated > + flexible array members. Use the new command-line option > + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing > + array of a structure as a flexible array member at different levels. <code>-fstrict-flex-arrays</code> to control which trailing array members are streated as flexible arrays. I've also just now noticed that there's now a flag_strict_flex_arrays check in the middle-end (in array bound diagnostics) but this option isn't streamed or handled with LTO. I think you want to replace that with the appropriate DECL_NOT_FLEXARRAY check. We might also want to see how inlining accesses from TUs with different -fstrict-flex-arrays setting behaves when accessing the same structure (and whether we might want to issue an ODR style diagnostic there). Thanks, Richard.
Hi, Richard, Thanks a lot for your comments. > On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: > > On Tue, 20 Dec 2022, Qing Zhao wrote: > >> Hi, >> >> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. >> >> Let me know if you have any comment or suggestions. > > Some copy editing below > >> Thanks. >> >> Qing. >> >> ======================================= >> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 >> From: Qing Zhao <qing.zhao@oracle.com> >> Date: Tue, 20 Dec 2022 16:13:04 +0000 >> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. >> >> --- >> htdocs/gcc-13/changes.html | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html >> index 689178f9..47b3d40f 100644 >> --- a/htdocs/gcc-13/changes.html >> +++ b/htdocs/gcc-13/changes.html >> @@ -39,6 +39,10 @@ a work-in-progress.</p> >> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed >> and the option is ignored right now.</li> >> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> >> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds >> + accesses to trailing struct members of one-element array type anymore. Please >> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat >> + trailing arrays of structures as flexible array members. </li> > > "Instead it diagnoses accesses to trailing arrays according to > <code>-fstrict-flex-arrays</code>." Okay. > >> </ul> >> >> >> @@ -409,6 +413,17 @@ a work-in-progress.</p> >> <h2>Other significant improvements</h2> >> >> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> >> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> >> + >> +<ul> >> + <li>GCC can now control when to treat the trailing array of a structure as a >> + flexible array member for the purpose of accessing the elements of such >> + an array. By default, all trailing arrays of structures are treated as > > all trailing arrays in aggregates are treated Okay. > >> + flexible array members. Use the new command-line option >> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing >> + array of a structure as a flexible array member at different levels. > > <code>-fstrict-flex-arrays</code> to control which trailing array > members are streated as flexible arrays. Okay. > > I've also just now noticed that there's now a flag_strict_flex_arrays > check in the middle-end (in array bound diagnostics) but this option > isn't streamed or handled with LTO. I think you want to replace that > with the appropriate DECL_NOT_FLEXARRAY check. We need to know the level value of the strict_flex_arrays on the struct field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY does not include such info. So, what should I do? Streaming the flag_strict_flex_arrays with LTO? > We might also want > to see how inlining accesses from TUs with different -fstrict-flex-arrays > setting behaves when accessing the same structure (and whether we might > want to issue an ODR style diagnostic there). Yes, good point, I will check on this part. BTW, a stupid question: what does ODR mean? thanks. Qing > > Thanks, > Richard.
On Wed, 21 Dec 2022, Qing Zhao wrote: > Hi, Richard, > > Thanks a lot for your comments. > > > On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: > > > > On Tue, 20 Dec 2022, Qing Zhao wrote: > > > >> Hi, > >> > >> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. > >> > >> Let me know if you have any comment or suggestions. > > > > Some copy editing below > > > >> Thanks. > >> > >> Qing. > >> > >> ======================================= > >> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 > >> From: Qing Zhao <qing.zhao@oracle.com> > >> Date: Tue, 20 Dec 2022 16:13:04 +0000 > >> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. > >> > >> --- > >> htdocs/gcc-13/changes.html | 15 +++++++++++++++ > >> 1 file changed, 15 insertions(+) > >> > >> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html > >> index 689178f9..47b3d40f 100644 > >> --- a/htdocs/gcc-13/changes.html > >> +++ b/htdocs/gcc-13/changes.html > >> @@ -39,6 +39,10 @@ a work-in-progress.</p> > >> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed > >> and the option is ignored right now.</li> > >> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> > >> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds > >> + accesses to trailing struct members of one-element array type anymore. Please > >> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat > >> + trailing arrays of structures as flexible array members. </li> > > > > "Instead it diagnoses accesses to trailing arrays according to > > <code>-fstrict-flex-arrays</code>." > > Okay. > > > >> </ul> > >> > >> > >> @@ -409,6 +413,17 @@ a work-in-progress.</p> > >> <h2>Other significant improvements</h2> > >> > >> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> > >> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> > >> + > >> +<ul> > >> + <li>GCC can now control when to treat the trailing array of a structure as a > >> + flexible array member for the purpose of accessing the elements of such > >> + an array. By default, all trailing arrays of structures are treated as > > > > all trailing arrays in aggregates are treated > Okay. > > > >> + flexible array members. Use the new command-line option > >> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing > >> + array of a structure as a flexible array member at different levels. > > > > <code>-fstrict-flex-arrays</code> to control which trailing array > > members are streated as flexible arrays. > > Okay. > > > > > I've also just now noticed that there's now a flag_strict_flex_arrays > > check in the middle-end (in array bound diagnostics) but this option > > isn't streamed or handled with LTO. I think you want to replace that > > with the appropriate DECL_NOT_FLEXARRAY check. > > We need to know the level value of the strict_flex_arrays on the struct > field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY > does not include such info. So, what should I do? Streaming the > flag_strict_flex_arrays with LTO? But you do if (compref) { /* Try to determine special array member type for this COMPONENT_REF. */ sam = component_ref_sam_type (arg); /* Get the level of strict_flex_array for this array field. */ tree afield_decl = TREE_OPERAND (arg, 1); strict_flex_array_level = strict_flex_array_level_of (afield_decl); I see that function doesn't look at DECL_NOT_FLEXARRAY but just checks attributes (those are streamed in LTO). OK, so I suppose the diagnostic itself would become just less precise as in "trailing array %qT should not be used as a flexible array member" without the "for level N and above" part of the diagnostic? > > We might also want > > to see how inlining accesses from TUs with different -fstrict-flex-arrays > > setting behaves when accessing the same structure (and whether we might > > want to issue an ODR style diagnostic there). This mixing also means streaming -fstrict-flex-arrays won't be of much help in general. > Yes, good point, I will check on this part. > > BTW, a stupid question: what does ODR mean? It's the One-Definition-Rule (of C++). Basically we'd diagnose same struct declarations with different -fstrict-flex-arrays setting. I see we miss comparing DECL_NOT_FLEXARRAY for tree merging, I'm testing a patch to fix that now. Richard. > thanks. > > Qing > > > > Thanks, > > Richard. > >
> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote: > > On Wed, 21 Dec 2022, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for your comments. >> >>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: >>> >>> On Tue, 20 Dec 2022, Qing Zhao wrote: >>> >>>> Hi, >>>> >>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. >>>> >>>> Let me know if you have any comment or suggestions. >>> >>> Some copy editing below >>> >>>> Thanks. >>>> >>>> Qing. >>>> >>>> ======================================= >>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 >>>> From: Qing Zhao <qing.zhao@oracle.com> >>>> Date: Tue, 20 Dec 2022 16:13:04 +0000 >>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. >>>> >>>> --- >>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++ >>>> 1 file changed, 15 insertions(+) >>>> >>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html >>>> index 689178f9..47b3d40f 100644 >>>> --- a/htdocs/gcc-13/changes.html >>>> +++ b/htdocs/gcc-13/changes.html >>>> @@ -39,6 +39,10 @@ a work-in-progress.</p> >>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed >>>> and the option is ignored right now.</li> >>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> >>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds >>>> + accesses to trailing struct members of one-element array type anymore. Please >>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat >>>> + trailing arrays of structures as flexible array members. </li> >>> >>> "Instead it diagnoses accesses to trailing arrays according to >>> <code>-fstrict-flex-arrays</code>." >> >> Okay. >>> >>>> </ul> >>>> >>>> >>>> @@ -409,6 +413,17 @@ a work-in-progress.</p> >>>> <h2>Other significant improvements</h2> >>>> >>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> >>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> >>>> + >>>> +<ul> >>>> + <li>GCC can now control when to treat the trailing array of a structure as a >>>> + flexible array member for the purpose of accessing the elements of such >>>> + an array. By default, all trailing arrays of structures are treated as >>> >>> all trailing arrays in aggregates are treated >> Okay. >>> >>>> + flexible array members. Use the new command-line option >>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing >>>> + array of a structure as a flexible array member at different levels. >>> >>> <code>-fstrict-flex-arrays</code> to control which trailing array >>> members are streated as flexible arrays. >> >> Okay. >> >>> >>> I've also just now noticed that there's now a flag_strict_flex_arrays >>> check in the middle-end (in array bound diagnostics) but this option >>> isn't streamed or handled with LTO. I think you want to replace that >>> with the appropriate DECL_NOT_FLEXARRAY check. >> >> We need to know the level value of the strict_flex_arrays on the struct >> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY >> does not include such info. So, what should I do? Streaming the >> flag_strict_flex_arrays with LTO? > > But you do > > if (compref) > { > /* Try to determine special array member type for this > COMPONENT_REF. */ > sam = component_ref_sam_type (arg); > /* Get the level of strict_flex_array for this array field. */ > tree afield_decl = TREE_OPERAND (arg, 1); > strict_flex_array_level = strict_flex_array_level_of (afield_decl); > > I see that function doesn't look at DECL_NOT_FLEXARRAY but just > checks attributes (those are streamed in LTO). Yes, checked both flag_strict_flex_arrays and attributes. There are two places in middle end calling “strict_flex_array_level_of” function, one inside “array_bounds_checker::check_array_ref”, another one inside “component_ref_size”. Shall we check DECL_NOT_FLEXARRAY field instead of calling “strict_flex_array_level_of” in both places? > > OK, so I suppose the diagnostic itself would become just less precise > as in "trailing array %qT should not be used as a flexible array member" > without the "for level N and above" part of the diagnostic? Yes, that might be the major impact. If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter? > >>> We might also want >>> to see how inlining accesses from TUs with different -fstrict-flex-arrays >>> setting behaves when accessing the same structure (and whether we might >>> want to issue an ODR style diagnostic there). > > This mixing also means streaming -fstrict-flex-arrays won't be of much > help in general. Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it? > >> Yes, good point, I will check on this part. >> >> BTW, a stupid question: what does ODR mean? > > It's the One-Definition-Rule (of C++). Basically we'd diagnose > same struct declarations with different -fstrict-flex-arrays setting. > I see we miss comparing DECL_NOT_FLEXARRAY for tree merging, I'm > testing a patch to fix that now. Okay, thanks a lot for the help. Qing > > Richard. > >> thanks. >> >> Qing >>> >>> Thanks, >>> Richard. >> >> > > -- > Richard Biener <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, > Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; > HRB 36809 (AG Nuernberg)
On Thu, 22 Dec 2022, Qing Zhao wrote: > > > > On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote: > > > > On Wed, 21 Dec 2022, Qing Zhao wrote: > > > >> Hi, Richard, > >> > >> Thanks a lot for your comments. > >> > >>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: > >>> > >>> On Tue, 20 Dec 2022, Qing Zhao wrote: > >>> > >>>> Hi, > >>>> > >>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. > >>>> > >>>> Let me know if you have any comment or suggestions. > >>> > >>> Some copy editing below > >>> > >>>> Thanks. > >>>> > >>>> Qing. > >>>> > >>>> ======================================= > >>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 > >>>> From: Qing Zhao <qing.zhao@oracle.com> > >>>> Date: Tue, 20 Dec 2022 16:13:04 +0000 > >>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. > >>>> > >>>> --- > >>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++ > >>>> 1 file changed, 15 insertions(+) > >>>> > >>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html > >>>> index 689178f9..47b3d40f 100644 > >>>> --- a/htdocs/gcc-13/changes.html > >>>> +++ b/htdocs/gcc-13/changes.html > >>>> @@ -39,6 +39,10 @@ a work-in-progress.</p> > >>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed > >>>> and the option is ignored right now.</li> > >>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> > >>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds > >>>> + accesses to trailing struct members of one-element array type anymore. Please > >>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat > >>>> + trailing arrays of structures as flexible array members. </li> > >>> > >>> "Instead it diagnoses accesses to trailing arrays according to > >>> <code>-fstrict-flex-arrays</code>." > >> > >> Okay. > >>> > >>>> </ul> > >>>> > >>>> > >>>> @@ -409,6 +413,17 @@ a work-in-progress.</p> > >>>> <h2>Other significant improvements</h2> > >>>> > >>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> > >>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> > >>>> + > >>>> +<ul> > >>>> + <li>GCC can now control when to treat the trailing array of a structure as a > >>>> + flexible array member for the purpose of accessing the elements of such > >>>> + an array. By default, all trailing arrays of structures are treated as > >>> > >>> all trailing arrays in aggregates are treated > >> Okay. > >>> > >>>> + flexible array members. Use the new command-line option > >>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing > >>>> + array of a structure as a flexible array member at different levels. > >>> > >>> <code>-fstrict-flex-arrays</code> to control which trailing array > >>> members are streated as flexible arrays. > >> > >> Okay. > >> > >>> > >>> I've also just now noticed that there's now a flag_strict_flex_arrays > >>> check in the middle-end (in array bound diagnostics) but this option > >>> isn't streamed or handled with LTO. I think you want to replace that > >>> with the appropriate DECL_NOT_FLEXARRAY check. > >> > >> We need to know the level value of the strict_flex_arrays on the struct > >> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY > >> does not include such info. So, what should I do? Streaming the > >> flag_strict_flex_arrays with LTO? > > > > But you do > > > > if (compref) > > { > > /* Try to determine special array member type for this > > COMPONENT_REF. */ > > sam = component_ref_sam_type (arg); > > /* Get the level of strict_flex_array for this array field. */ > > tree afield_decl = TREE_OPERAND (arg, 1); > > strict_flex_array_level = strict_flex_array_level_of (afield_decl); > > > > I see that function doesn't look at DECL_NOT_FLEXARRAY but just > > checks attributes (those are streamed in LTO). > > Yes, checked both flag_strict_flex_arrays and attributes. > > There are two places in middle end calling ?strict_flex_array_level_of? function, > one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?. > Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places? I wonder if that function should check DECL_NOT_FLEXARRAY? > > > > OK, so I suppose the diagnostic itself would become just less precise > > as in "trailing array %qT should not be used as a flexible array member" > > without the "for level N and above" part of the diagnostic? > > Yes, that might be the major impact. > > If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter? I think the main information is preserved in diagnosing the flex vs. non-flex array assumption. > > > >>> We might also want > >>> to see how inlining accesses from TUs with different -fstrict-flex-arrays > >>> setting behaves when accessing the same structure (and whether we might > >>> want to issue an ODR style diagnostic there). > > > > This mixing also means streaming -fstrict-flex-arrays won't be of much > > help in general. > > Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it? I think in similar situations we try to DWIM, but in some cases it will result in "garbage" behavior. I don't think there's anything we can do here besides trying to diagnose such mismatches with -flto at the WPA stage. Richard.
> On Jan 9, 2023, at 2:11 AM, Richard Biener <rguenther@suse.de> wrote: > > On Thu, 22 Dec 2022, Qing Zhao wrote: > >> >> >>> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote: >>> >>> On Wed, 21 Dec 2022, Qing Zhao wrote: >>> >>>> Hi, Richard, >>>> >>>> Thanks a lot for your comments. >>>> >>>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: >>>>> >>>>> On Tue, 20 Dec 2022, Qing Zhao wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. >>>>>> >>>>>> Let me know if you have any comment or suggestions. >>>>> >>>>> Some copy editing below >>>>> >>>>>> Thanks. >>>>>> >>>>>> Qing. >>>>>> >>>>>> ======================================= >>>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 >>>>>> From: Qing Zhao <qing.zhao@oracle.com> >>>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000 >>>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. >>>>>> >>>>>> --- >>>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++ >>>>>> 1 file changed, 15 insertions(+) >>>>>> >>>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html >>>>>> index 689178f9..47b3d40f 100644 >>>>>> --- a/htdocs/gcc-13/changes.html >>>>>> +++ b/htdocs/gcc-13/changes.html >>>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p> >>>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed >>>>>> and the option is ignored right now.</li> >>>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> >>>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds >>>>>> + accesses to trailing struct members of one-element array type anymore. Please >>>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat >>>>>> + trailing arrays of structures as flexible array members. </li> >>>>> >>>>> "Instead it diagnoses accesses to trailing arrays according to >>>>> <code>-fstrict-flex-arrays</code>." >>>> >>>> Okay. >>>>> >>>>>> </ul> >>>>>> >>>>>> >>>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p> >>>>>> <h2>Other significant improvements</h2> >>>>>> >>>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> >>>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> >>>>>> + >>>>>> +<ul> >>>>>> + <li>GCC can now control when to treat the trailing array of a structure as a >>>>>> + flexible array member for the purpose of accessing the elements of such >>>>>> + an array. By default, all trailing arrays of structures are treated as >>>>> >>>>> all trailing arrays in aggregates are treated >>>> Okay. >>>>> >>>>>> + flexible array members. Use the new command-line option >>>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing >>>>>> + array of a structure as a flexible array member at different levels. >>>>> >>>>> <code>-fstrict-flex-arrays</code> to control which trailing array >>>>> members are streated as flexible arrays. >>>> >>>> Okay. >>>> >>>>> >>>>> I've also just now noticed that there's now a flag_strict_flex_arrays >>>>> check in the middle-end (in array bound diagnostics) but this option >>>>> isn't streamed or handled with LTO. I think you want to replace that >>>>> with the appropriate DECL_NOT_FLEXARRAY check. >>>> >>>> We need to know the level value of the strict_flex_arrays on the struct >>>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY >>>> does not include such info. So, what should I do? Streaming the >>>> flag_strict_flex_arrays with LTO? >>> >>> But you do >>> >>> if (compref) >>> { >>> /* Try to determine special array member type for this >>> COMPONENT_REF. */ >>> sam = component_ref_sam_type (arg); >>> /* Get the level of strict_flex_array for this array field. */ >>> tree afield_decl = TREE_OPERAND (arg, 1); >>> strict_flex_array_level = strict_flex_array_level_of (afield_decl); >>> >>> I see that function doesn't look at DECL_NOT_FLEXARRAY but just >>> checks attributes (those are streamed in LTO). >> >> Yes, checked both flag_strict_flex_arrays and attributes. >> >> There are two places in middle end calling ?strict_flex_array_level_of? function, >> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?. >> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places? > > I wonder if that function should check DECL_NOT_FLEXARRAY? The function “strict_flex_array_level_of” is intended to query the LEVEL of strict_flex_array, only check DECL_NOT_FLEXARRAY is not enough. So, I think the major question here is: Do we need the LEVEL of strict_flex_array information in the Middle end? The current major use of LEVEL of strict_flex_array in the middle end is two places: 1. In the routine “component_ref_size”: to determine the size of the trailing array based on the level of the strict_flex_array. 2. In the routine “array_bounds_checker::check_array_ref”: to issue different information for -Wstrict-flex-array based on different level. Just double checked the above 1, and 2. Without LEVEL of strict_flex_array info, 1 should be fine 2, as you mentioned previously, the major impact will be that the LEVEL information is lost in the issued message, but that might be not a big issue. So, I will try to eliminate the reference to “flag_strict_flex_array” in the middle end, replace it with “DECL_NOT_FLEXARRAY”, and come up with an updated patch for this change. How do you think? > >>> >>> OK, so I suppose the diagnostic itself would become just less precise >>> as in "trailing array %qT should not be used as a flexible array member" >>> without the "for level N and above" part of the diagnostic? >> >> Yes, that might be the major impact. >> >> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter? > > I think the main information is preserved in diagnosing the flex vs. > non-flex array assumption. Yes. Agreed. > >>> >>>>> We might also want >>>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays >>>>> setting behaves when accessing the same structure (and whether we might >>>>> want to issue an ODR style diagnostic there). >>> >>> This mixing also means streaming -fstrict-flex-arrays won't be of much >>> help in general. >> >> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it? > > I think in similar situations we try to DWIM, but in some cases it will > result in "garbage" behavior. I don't think there's anything we can > do here besides trying to diagnose such mismatches with -flto at the WPA > stage. Shall we issue warning for such mismatches? Where is the place I can add such warnings? thanks. Qing > > Richard.
On Mon, 9 Jan 2023, Qing Zhao wrote: > > > > On Jan 9, 2023, at 2:11 AM, Richard Biener <rguenther@suse.de> wrote: > > > > On Thu, 22 Dec 2022, Qing Zhao wrote: > > > >> > >> > >>> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote: > >>> > >>> On Wed, 21 Dec 2022, Qing Zhao wrote: > >>> > >>>> Hi, Richard, > >>>> > >>>> Thanks a lot for your comments. > >>>> > >>>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: > >>>>> > >>>>> On Tue, 20 Dec 2022, Qing Zhao wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. > >>>>>> > >>>>>> Let me know if you have any comment or suggestions. > >>>>> > >>>>> Some copy editing below > >>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> Qing. > >>>>>> > >>>>>> ======================================= > >>>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 > >>>>>> From: Qing Zhao <qing.zhao@oracle.com> > >>>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000 > >>>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. > >>>>>> > >>>>>> --- > >>>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++ > >>>>>> 1 file changed, 15 insertions(+) > >>>>>> > >>>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html > >>>>>> index 689178f9..47b3d40f 100644 > >>>>>> --- a/htdocs/gcc-13/changes.html > >>>>>> +++ b/htdocs/gcc-13/changes.html > >>>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p> > >>>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed > >>>>>> and the option is ignored right now.</li> > >>>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> > >>>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds > >>>>>> + accesses to trailing struct members of one-element array type anymore. Please > >>>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat > >>>>>> + trailing arrays of structures as flexible array members. </li> > >>>>> > >>>>> "Instead it diagnoses accesses to trailing arrays according to > >>>>> <code>-fstrict-flex-arrays</code>." > >>>> > >>>> Okay. > >>>>> > >>>>>> </ul> > >>>>>> > >>>>>> > >>>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p> > >>>>>> <h2>Other significant improvements</h2> > >>>>>> > >>>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> > >>>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> > >>>>>> + > >>>>>> +<ul> > >>>>>> + <li>GCC can now control when to treat the trailing array of a structure as a > >>>>>> + flexible array member for the purpose of accessing the elements of such > >>>>>> + an array. By default, all trailing arrays of structures are treated as > >>>>> > >>>>> all trailing arrays in aggregates are treated > >>>> Okay. > >>>>> > >>>>>> + flexible array members. Use the new command-line option > >>>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing > >>>>>> + array of a structure as a flexible array member at different levels. > >>>>> > >>>>> <code>-fstrict-flex-arrays</code> to control which trailing array > >>>>> members are streated as flexible arrays. > >>>> > >>>> Okay. > >>>> > >>>>> > >>>>> I've also just now noticed that there's now a flag_strict_flex_arrays > >>>>> check in the middle-end (in array bound diagnostics) but this option > >>>>> isn't streamed or handled with LTO. I think you want to replace that > >>>>> with the appropriate DECL_NOT_FLEXARRAY check. > >>>> > >>>> We need to know the level value of the strict_flex_arrays on the struct > >>>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY > >>>> does not include such info. So, what should I do? Streaming the > >>>> flag_strict_flex_arrays with LTO? > >>> > >>> But you do > >>> > >>> if (compref) > >>> { > >>> /* Try to determine special array member type for this > >>> COMPONENT_REF. */ > >>> sam = component_ref_sam_type (arg); > >>> /* Get the level of strict_flex_array for this array field. */ > >>> tree afield_decl = TREE_OPERAND (arg, 1); > >>> strict_flex_array_level = strict_flex_array_level_of (afield_decl); > >>> > >>> I see that function doesn't look at DECL_NOT_FLEXARRAY but just > >>> checks attributes (those are streamed in LTO). > >> > >> Yes, checked both flag_strict_flex_arrays and attributes. > >> > >> There are two places in middle end calling ?strict_flex_array_level_of? function, > >> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?. > >> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places? > > > > I wonder if that function should check DECL_NOT_FLEXARRAY? > > The function ?strict_flex_array_level_of? is intended to query the LEVEL of strict_flex_array, only check DECL_NOT_FLEXARRAY is not enough. > > So, I think the major question here is: > > Do we need the LEVEL of strict_flex_array information in the Middle end? > > The current major use of LEVEL of strict_flex_array in the middle end is two places: > > 1. In the routine ?component_ref_size?: to determine the size of the trailing array based on the level of the strict_flex_array. > 2. In the routine ?array_bounds_checker::check_array_ref?: to issue different information for -Wstrict-flex-array based on different level. > > > Just double checked the above 1, and 2. Without LEVEL of strict_flex_array info, 1 should be fine > 2, as you mentioned previously, the major impact will be that the LEVEL information is lost in the issued message, but that might be not a big > issue. > > So, I will try to eliminate the reference to ?flag_strict_flex_array? in the middle end, replace it with ?DECL_NOT_FLEXARRAY?, and come up with > an updated patch for this change. > > How do you think? Yes, that sounds good. > > > >>> > >>> OK, so I suppose the diagnostic itself would become just less precise > >>> as in "trailing array %qT should not be used as a flexible array member" > >>> without the "for level N and above" part of the diagnostic? > >> > >> Yes, that might be the major impact. > >> > >> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter? > > > > I think the main information is preserved in diagnosing the flex vs. > > non-flex array assumption. > Yes. Agreed. > > > > >>> > >>>>> We might also want > >>>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays > >>>>> setting behaves when accessing the same structure (and whether we might > >>>>> want to issue an ODR style diagnostic there). > >>> > >>> This mixing also means streaming -fstrict-flex-arrays won't be of much > >>> help in general. > >> > >> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it? > > > > I think in similar situations we try to DWIM, but in some cases it will > > result in "garbage" behavior. I don't think there's anything we can > > do here besides trying to diagnose such mismatches with -flto at the WPA > > stage. > > Shall we issue warning for such mismatches? Where is the place I can add such warnings? I'm not sure - we'd have to restrict it to "used" types and in principle only when actual objects pass from one TU to another with different flex-array semantics. Otherwise we'll risk tons of diagnostics when people "forget" -fstrict-flex-arrays on some TUs but pull in common headers. The C++ ODR diagnostics reside in ipa-devirt.cc, I'm not sure diagnostics on flex arrays would fit there. I just wanted to bring this up, I do not have a good idea how or where to implement it. Richard. > thanks. > > Qing > > > > Richard. > >
> On Jan 10, 2023, at 3:06 AM, Richard Biener <rguenther@suse.de> wrote: > > On Mon, 9 Jan 2023, Qing Zhao wrote: > >> >> >>> On Jan 9, 2023, at 2:11 AM, Richard Biener <rguenther@suse.de> wrote: >>> >>> On Thu, 22 Dec 2022, Qing Zhao wrote: >>> >>>> >>>> >>>>> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote: >>>>> >>>>> On Wed, 21 Dec 2022, Qing Zhao wrote: >>>>> >>>>>> Hi, Richard, >>>>>> >>>>>> Thanks a lot for your comments. >>>>>> >>>>>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote: >>>>>>> >>>>>>> On Tue, 20 Dec 2022, Qing Zhao wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html. >>>>>>>> >>>>>>>> Let me know if you have any comment or suggestions. >>>>>>> >>>>>>> Some copy editing below >>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Qing. >>>>>>>> >>>>>>>> ======================================= >>>>>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001 >>>>>>>> From: Qing Zhao <qing.zhao@oracle.com> >>>>>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000 >>>>>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact. >>>>>>>> >>>>>>>> --- >>>>>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++ >>>>>>>> 1 file changed, 15 insertions(+) >>>>>>>> >>>>>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html >>>>>>>> index 689178f9..47b3d40f 100644 >>>>>>>> --- a/htdocs/gcc-13/changes.html >>>>>>>> +++ b/htdocs/gcc-13/changes.html >>>>>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p> >>>>>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed >>>>>>>> and the option is ignored right now.</li> >>>>>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> >>>>>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds >>>>>>>> + accesses to trailing struct members of one-element array type anymore. Please >>>>>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat >>>>>>>> + trailing arrays of structures as flexible array members. </li> >>>>>>> >>>>>>> "Instead it diagnoses accesses to trailing arrays according to >>>>>>> <code>-fstrict-flex-arrays</code>." >>>>>> >>>>>> Okay. >>>>>>> >>>>>>>> </ul> >>>>>>>> >>>>>>>> >>>>>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p> >>>>>>>> <h2>Other significant improvements</h2> >>>>>>>> >>>>>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> >>>>>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> >>>>>>>> + >>>>>>>> +<ul> >>>>>>>> + <li>GCC can now control when to treat the trailing array of a structure as a >>>>>>>> + flexible array member for the purpose of accessing the elements of such >>>>>>>> + an array. By default, all trailing arrays of structures are treated as >>>>>>> >>>>>>> all trailing arrays in aggregates are treated >>>>>> Okay. >>>>>>> >>>>>>>> + flexible array members. Use the new command-line option >>>>>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing >>>>>>>> + array of a structure as a flexible array member at different levels. >>>>>>> >>>>>>> <code>-fstrict-flex-arrays</code> to control which trailing array >>>>>>> members are streated as flexible arrays. >>>>>> >>>>>> Okay. >>>>>> >>>>>>> >>>>>>> I've also just now noticed that there's now a flag_strict_flex_arrays >>>>>>> check in the middle-end (in array bound diagnostics) but this option >>>>>>> isn't streamed or handled with LTO. I think you want to replace that >>>>>>> with the appropriate DECL_NOT_FLEXARRAY check. >>>>>> >>>>>> We need to know the level value of the strict_flex_arrays on the struct >>>>>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY >>>>>> does not include such info. So, what should I do? Streaming the >>>>>> flag_strict_flex_arrays with LTO? >>>>> >>>>> But you do >>>>> >>>>> if (compref) >>>>> { >>>>> /* Try to determine special array member type for this >>>>> COMPONENT_REF. */ >>>>> sam = component_ref_sam_type (arg); >>>>> /* Get the level of strict_flex_array for this array field. */ >>>>> tree afield_decl = TREE_OPERAND (arg, 1); >>>>> strict_flex_array_level = strict_flex_array_level_of (afield_decl); >>>>> >>>>> I see that function doesn't look at DECL_NOT_FLEXARRAY but just >>>>> checks attributes (those are streamed in LTO). >>>> >>>> Yes, checked both flag_strict_flex_arrays and attributes. >>>> >>>> There are two places in middle end calling ?strict_flex_array_level_of? function, >>>> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?. >>>> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places? >>> >>> I wonder if that function should check DECL_NOT_FLEXARRAY? >> >> The function ?strict_flex_array_level_of? is intended to query the LEVEL of strict_flex_array, only check DECL_NOT_FLEXARRAY is not enough. >> >> So, I think the major question here is: >> >> Do we need the LEVEL of strict_flex_array information in the Middle end? >> >> The current major use of LEVEL of strict_flex_array in the middle end is two places: >> >> 1. In the routine ?component_ref_size?: to determine the size of the trailing array based on the level of the strict_flex_array. >> 2. In the routine ?array_bounds_checker::check_array_ref?: to issue different information for -Wstrict-flex-array based on different level. >> >> >> Just double checked the above 1, and 2. Without LEVEL of strict_flex_array info, 1 should be fine >> 2, as you mentioned previously, the major impact will be that the LEVEL information is lost in the issued message, but that might be not a big >> issue. >> >> So, I will try to eliminate the reference to ?flag_strict_flex_array? in the middle end, replace it with ?DECL_NOT_FLEXARRAY?, and come up with >> an updated patch for this change. >> >> How do you think? > > Yes, that sounds good. Will do that. > >>> >>>>> >>>>> OK, so I suppose the diagnostic itself would become just less precise >>>>> as in "trailing array %qT should not be used as a flexible array member" >>>>> without the "for level N and above" part of the diagnostic? >>>> >>>> Yes, that might be the major impact. >>>> >>>> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter? >>> >>> I think the main information is preserved in diagnosing the flex vs. >>> non-flex array assumption. >> Yes. Agreed. >> >>> >>>>> >>>>>>> We might also want >>>>>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays >>>>>>> setting behaves when accessing the same structure (and whether we might >>>>>>> want to issue an ODR style diagnostic there). >>>>> >>>>> This mixing also means streaming -fstrict-flex-arrays won't be of much >>>>> help in general. >>>> >>>> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it? >>> >>> I think in similar situations we try to DWIM, but in some cases it will >>> result in "garbage" behavior. I don't think there's anything we can >>> do here besides trying to diagnose such mismatches with -flto at the WPA >>> stage. >> >> Shall we issue warning for such mismatches? Where is the place I can add such warnings? > > I'm not sure - we'd have to restrict it to "used" types and in principle > only when actual objects pass from one TU to another with different > flex-array semantics. Otherwise we'll risk tons of diagnostics when > people "forget" -fstrict-flex-arrays on some TUs but pull in common > headers. > > The C++ ODR diagnostics reside in ipa-devirt.cc, I'm not sure diagnostics > on flex arrays would fit there. > > I just wanted to bring this up, I do not have a good idea how or where > to implement it. Thanks for the information. Will study this a little bit later. Qing > > Richard. > >> thanks. >> >> Qing >>> >>> Richard. >> >> > > -- > Richard Biener <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, > Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; > HRB 36809 (AG Nuernberg)
On Tue, 20 Dec 2022, Qing Zhao via Gcc-patches wrote:
> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
Please note that ids must not contain white space.
Would you mind following up making this "flexiblearray" or similiar?
Thank you,
Gerald
Thanks for the comment.
I just committed the following:
From fc681f5412c421ff9609aea448310106d2570fd5 Mon Sep 17 00:00:00 2001
From: Qing Zhao <qing.zhao@oracle.com>
Date: Tue, 17 Jan 2023 15:52:15 +0000
Subject: [PATCH] gcc13/changes: update id 'flexible array' to
'flexible-arrays' since ids must not contain white space
---
htdocs/gcc-13/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 08e36fb3..ca9cd2da 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -438,7 +438,7 @@ a work-in-progress.</p>
<h2>Other significant improvements</h2>
<!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
-<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
+<h3 id="flexible-arrays">Treating trailing arrays as flexible array members</h3>
<ul>
<li>GCC can now control when to treat the trailing array of a structure as a
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 689178f9..47b3d40f 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -39,6 +39,10 @@ a work-in-progress.</p> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed and the option is ignored right now.</li> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds + accesses to trailing struct members of one-element array type anymore. Please + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat + trailing arrays of structures as flexible array members. </li> </ul> @@ -409,6 +413,17 @@ a work-in-progress.</p> <h2>Other significant improvements</h2> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> --> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3> + +<ul> + <li>GCC can now control when to treat the trailing array of a structure as a + flexible array member for the purpose of accessing the elements of such + an array. By default, all trailing arrays of structures are treated as + flexible array members. Use the new command-line option + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing + array of a structure as a flexible array member at different levels. + </li> +</ul> <!-- .................................................................. --> <!-- <h2 id="13.1">GCC 13.1</h2> -->