[middle-end/104550] Suppress uninitialized warnings for new created uses from __builtin_clear_padding folding
Message ID | DFB3B04D-EA1E-4F05-9E65-F02A3FB2EEF5@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 898883947413 for <patchwork@sourceware.org>; Tue, 22 Feb 2022 17:21:36 +0000 (GMT) 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 4FE753857818 for <gcc-patches@gcc.gnu.org>; Tue, 22 Feb 2022 17:21:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4FE753857818 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 21MFKjOE032180; Tue, 22 Feb 2022 17:21:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=KARAG4LVBbybIOpYpxVQKBO/t2XbVUOsJ2khTvFA4NM=; b=jS3jQF1jZccK3oOLixYZ4NNkZqIBguoEU4dGcK7mqsopASMGaLUYi+Ki9MXuuaol/dWp u7UyiotdmIwIBynvhBMOREtmgDSg/Dlf3ik/xX9w+LKK32GW/H6gbQ/qwk4rW9bWx0WA dqJf27QlpDXDMUQLoGtQxyjhPZaCN7FnejnPQvYNVIyHt6hAOKWRbb9JJTTK+LMpmFJQ wkTTQQdvQtYmsihz9H/ptLGzb3752syOVNMW4B+w1uakqUKTx5oHxbcNbyS7MTFr2Q5a 70PEcCz0aO2IlcUQVe702uHrxV1d1DEqqx1+T6i6gdUez1+scAUCGg49BhCTdqvsSwoi qw== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by mx0b-00069f02.pphosted.com with ESMTP id 3ecv6esm8q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Feb 2022 17:21:17 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 21MHAsiU087273; Tue, 22 Feb 2022 17:21:16 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2107.outbound.protection.outlook.com [104.47.70.107]) by aserp3030.oracle.com with ESMTP id 3eapkg9x6a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Feb 2022 17:21:16 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JKJ6GJMvC18BHGRp7sPwMhUCjOi9nhNdhR68jyvxQvJAKLUX/tx3GTsPwsfPZOhBwkv6npRzP00eD32uxe2qdy2ToZHRdGLYKp40QABhcC6taiCPh//ZPgW4zLo1xnRsKxxF0zKqLZNHUj/caa+n/o/RhagyVaz4ogiQygXSKH/e5FrZPxLMN/p00ewLZrkMFmRQMrL/Io7hN0h5Fkaiori0vcjDaFJKC1nS2DOkZqWVQaujq1994wvGDxw01PG9wvM/pMEkcLAOFint+x6Mw/Q4qk+dZCd8sR80f7NVJ9p5kZKfyh0UfvMXWI0W9ui562RPzqD8Q74G71tMnxe+8Q== 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=KARAG4LVBbybIOpYpxVQKBO/t2XbVUOsJ2khTvFA4NM=; b=m2BxcLtPxLTeHqcLt/surs1TfFS//+weteDIZRyvPKmdG4INwBNiGnA0P0hG4Clw2t8KMjCf7mtpIGfqd/JCVSuw0BiKOK/Zxc5KJg/SMNrHwKZUcPUqYBIIrsTVveeQE2mj5gAnSiVIEABG2HSy7tuYK1vEq8PNh1MFiWR3Ee2ocrUO8ENu5hquB1VfJCP4lAUXS8vBOjjItcvwd42GpbJU47zGPO+jDW9pm1VyQBLFcl6wG2/5M6nAgtNtKnOyLj5D/zrYrZbG5lNWxgejvFzL3WkjZ+RDEU9k20AbZbOq6HgI71JaJBf4wRtZJkrGzE3d7wVi8Xp7MZ04Loi+jw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KARAG4LVBbybIOpYpxVQKBO/t2XbVUOsJ2khTvFA4NM=; b=0GQ5/IhsUMDY1GZtnbwg3fhveJXbcbhrzRCX76N4kfIcBSnkRmaax1puQcch+PtXBmMaOipQTGJqLNwFe/aPANbqR68NMvOqjur3baGn02G9ZtEfKCsZ2Nk/Mqe0Y/FXpx6yTBs4kCXtp0xeulE7vlyh9YAeyZ272dYNWquF/Wo= Received: from CH2PR10MB4344.namprd10.prod.outlook.com (2603:10b6:610:af::19) by SJ0PR10MB5599.namprd10.prod.outlook.com (2603:10b6:a03:3dc::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.24; Tue, 22 Feb 2022 17:21:14 +0000 Received: from CH2PR10MB4344.namprd10.prod.outlook.com ([fe80::50e0:10b6:4c07:3728]) by CH2PR10MB4344.namprd10.prod.outlook.com ([fe80::50e0:10b6:4c07:3728%8]) with mapi id 15.20.5017.021; Tue, 22 Feb 2022 17:21:14 +0000 From: Qing Zhao <qing.zhao@oracle.com> To: jakub Jelinek <jakub@redhat.com> Subject: [PATCH][middle-end/104550]Suppress uninitialized warnings for new created uses from __builtin_clear_padding folding Thread-Topic: [PATCH][middle-end/104550]Suppress uninitialized warnings for new created uses from __builtin_clear_padding folding Thread-Index: AQHYKBCYiG2yQ4mnRUmPkikupba3Iw== Date: Tue, 22 Feb 2022 17:21:14 +0000 Message-ID: <DFB3B04D-EA1E-4F05-9E65-F02A3FB2EEF5@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.7) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad42bca0-04f9-4508-9208-08d9f627ba8b x-ms-traffictypediagnostic: SJ0PR10MB5599:EE_ x-microsoft-antispam-prvs: <SJ0PR10MB559989BC3775192137E567DE803B9@SJ0PR10MB5599.namprd10.prod.outlook.com> x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DstM9mK12ea0Wcu0Ku2CJpBTCXygANlO3MSawFlolKvV7FXHSa2x5hBIfHUVorytKzaSWqzV1cIxSou2V0I/sgk8Jbo/yfkTMGUy4Rurk25F35UhTHUUf7Y/4WO62U8vRDXFFA7pG6moIUOCVAXMvqQPKuOTFomZl22EGQRcu8Qeo4Tq7PfxQBOk7qfmgwfWf6PRlz6Ms4al6u7PvP4eCimtHxb0vwVNIkofuDstCiDXgIx4k709vroPT2mkkJ1KQqutrmAnI6XM35ebnqoE0o7YxvucLO4HhOEtj4c0iojMvoT2MkO1NmVnluxHBqLSn+PNIPcsiFxsMet63nTZu3koZ1kP09TaywI2znAjz2jZvRiPT3T6giJ/BK6MrEID3y9bzPBIVQyN+hb797xJYkDIAgW1r2dszmCpsnq6ckCRGTS8T3tLsI0N3vPhfIPyDYqSLL3XQB3fTCZfdd/I/e18/CBqQD//qlB5nE2obujBgOQz92NXpLvxDQxcio35118gIuLvexjfHIRoV78J396NhjSOEW133DZeakUk+BCWlabZPbZxj4RcyqHOY4uxQ16SE9WiMo/2npuYroz687O5bfF+iyvLgn8j3vt2VzWVIjqLK8CVqJMqDIp2l76wqfWXE9tp+NA/bpbA0JuZR1CRXkOHr78xJZeATqSQEm8fdl/T2HbbuUG27Y9bW6mliDc6596jqAQ2PuDly3crAQK3dVy2tCEea/H0bmUzqLeHvibOfGBewws1GV5+xQZmXoMmJnC8CmD2iDUNyyFEjimQe9r1zryL/oHfazBOj6P9KUgk5jacUSqDX0m5mzKxzVy3qerojB6WEl84dW4KDD/HAbIF37FfUAuqCY3w2cufUvdOPTKVQkwjrRaqPsge 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:(13230001)(366004)(66556008)(53546011)(66446008)(4326008)(38100700002)(2616005)(64756008)(5660300002)(86362001)(186003)(33656002)(2906002)(66476007)(6506007)(8936002)(8676002)(71200400001)(36756003)(38070700005)(316002)(6486002)(76116006)(66946007)(84970400001)(83380400001)(122000001)(91956017)(6916009)(54906003)(44832011)(508600001)(6512007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: L41xTmO/++ZOl5YN2Tc+V5wQVrQfhfPIdY5+BEvXIqPOKx6UB3NZC4u8wR7LkXPDzu+nNux7MvPJ7gu/RpQCcVfi6K8kA8VG3Xp+7xK36/OGnyEo0a+1R+OKjXob+VSgq7nn6K91GfZlUu3Xs6M3+/xzunMt9PzTZTak22sbFsHqzUPdiomzB6UzUy5SkGWUK06OfAUkjuUWZiS2a3jhMUJtIThKfb3Ow7DFT//2A8cYqJrwMllcEMz2Ki0BH4Z3NG9T+1m5FOXx8h7wbnmtEoEpw3iiXOMbFc0QmsoXBWfB3N5F48Jjtc00i/m0EwwkqODqFQGyGgR+uczVckIXw+X+edqTDH2M8zORpcmOKh+/NuEjNQXXTCq/RHHInJVfuEQSzUOTM4YvYkBwLTG1WV14wvQjL8F12SjrMDi0a8sXuNV8/STj+JQFR9hC3S/9SEWxhjKaNsGk0AgFWzV6l1P6ohyXZA9KCDydTSp5wxWU67CieipgjWRODR+XhLIEeE8CI0BB1e4dWY5EoVK3SbIKswFyHbx245JBHWNuGNgtnjT24NKmu8b84Eb/8vWT7puJ6/FysXiI+hXlR95GEw9bINu5uH3iFUgTABsfu2lykxuHX5MGQPBIDK4wAf1iODpLvbRTuKR7Ol902ONxlIE30WCHr0WUvmfN18v+kN5442/kBezWIpDGpC9RrMvagEU4I/tM8FgzT0Tp8+wp/0PoGxlu0+eKZxNo2iyzacGZMEyjJV7dY+dztAPtZwpRkH4y4rVwB3pHLV7neixXvwvCJc/hNO4Q9C6oVCYYDl5DiJee2SBNeS8ehCfMUCeA6nD85LsVkLfRHC9TY+ibALEPYgMSRAU/pb5hkcWB1Gd22X+GPUt5otgqfSTZ7pKomP6pZwWPNn+YX/RqYD4Kp438u5QEt8SmgkpyJ3bzzo34M/nwic3eTrrLV0IPgdL1ofFmA9zRtOgbQdPgoLJTQwuHzuua210d4sCY5ZVz3gxO+Jhmkb+enNoBF7D4Ih4DNkxinurK2WFtuqa1oKlL50VNIprwlVuKnOKQCYNJaARbd6lTWS+7EKeF5yr5XkcP7ECV8eavpGKPQ7keqN0CTEqnxCkkdY6PObnWaoUaezo39uRymlrpKKZMBMosBDEQfJQXazYTosy7BVbP9Js+B54xTmODWiWCpIvGAhMdkyYUyj4Sxm6b07k7fs6U1yZ0FfNi8F9p3/WiZMYeiWDubtV5gxb8JxbYbLBdooH95A7u95dzjjzbtI0AMtpoCknGu154/g9ujenJrfuiYDzuoe843klfWpxTm/KTscmohfniS5e13CvwhYePxHRcXjv194B48BL9RQj0oPry9Jp5UuvKbN4mmxynmjGTM3sIV6MATQFZR+AwP8ZR5YYs2t3hm78/0tU2ARjVSxB6obxc7jz51ekvAhnDbFco6RCyyqm/6rCEEFHaxZ/6zkl6G8+bg62Ga17D6/Jn3kh45dvY3A293jvkBFOJw5AzqM5iiRv2hMjcb3LtGgv6bpVojywl8bPa3/TD0rhdmdYE52/uo/TA4U3QdhL+W2cqGqseoRzUzMC3uwfKuUxBxy5OWhUjaNpe4vaGbvNmhHYQ0awQv21xTF8+1oNMTLz04jXVOekZXIShWqJUmLPHUtnRbKAiwO1ksadrq8lU0Qld7QYeJQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <82F9D331694A274481DF83CA66229392@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: ad42bca0-04f9-4508-9208-08d9f627ba8b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2022 17:21:14.2865 (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: iaqRhLXrmE/OizC7+KUn/MItT4geSA+xDUMYtWX5KmJ9S/37gw9xF70lvd8a+QGg8ISMyOrPaCqnFrU+nVdIsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5599 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10266 signatures=677939 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202220106 X-Proofpoint-GUID: 76P_L3KT4QWwCKoG0u-9hdjP18cE3b2Z X-Proofpoint-ORIG-GUID: 76P_L3KT4QWwCKoG0u-9hdjP18cE3b2Z X-Spam-Status: No, score=-11.3 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_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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> Cc: gcc-patches Paul A Clarke via <gcc-patches@gcc.gnu.org>, richard Biener <rguenther@suse.de> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[middle-end/104550] Suppress uninitialized warnings for new created uses from __builtin_clear_padding folding
|
|
Commit Message
Qing Zhao
Feb. 22, 2022, 5:21 p.m. UTC
__builtin_clear_padding(&object) will clear all the padding bits of the object.
actually, it doesn't involve any use of an user variable. Therefore, users do
not expect any uninitialized warning from it. It's reasonable to suppress
uninitialized warnings for all new created uses from __builtin_clear_padding
folding.
The patch has been bootstrapped and regress tested on both x86 and aarch64.
Okay for trunk?
Thanks.
Qing
======================================
From cf6620005f55d4a1f782332809445c270d22cf86 Mon Sep 17 00:00:00 2001
From: qing zhao <qing.zhao@oracle.com>
Date: Mon, 21 Feb 2022 16:38:31 +0000
Subject: [PATCH] Suppress uninitialized warnings for new created uses from
__builtin_clear_padding folding [PR104550]
__builtin_clear_padding(&object) will clear all the padding bits of the object.
actually, it doesn't involve any use of an user variable. Therefore, users do
not expect any uninitialized warning from it. It's reasonable to suppress
uninitialized warnings for all new created uses from __builtin_clear_padding
folding.
PR middle-end/104550
gcc/ChangeLog:
* gimple-fold.cc (clear_padding_flush): Suppress warnings for new
created uses.
(clear_padding_emit_loop): Likewise.
(clear_padding_type): Likewise.
(gimple_fold_builtin_clear_padding): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/auto-init-pr104550-1.c: New test.
* gcc.dg/auto-init-pr104550-2.c: New test.
* gcc.dg/auto-init-pr104550-3.c: New test.
---
gcc/gimple-fold.cc | 31 +++++++++++++++------
gcc/testsuite/gcc.dg/auto-init-pr104550-1.c | 10 +++++++
gcc/testsuite/gcc.dg/auto-init-pr104550-2.c | 11 ++++++++
gcc/testsuite/gcc.dg/auto-init-pr104550-3.c | 11 ++++++++
4 files changed, 55 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-1.c
create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-2.c
create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-3.c
Comments
On Tue, 22 Feb 2022, Qing Zhao wrote: > __builtin_clear_padding(&object) will clear all the padding bits of the object. > actually, it doesn't involve any use of an user variable. Therefore, users do > not expect any uninitialized warning from it. It's reasonable to suppress > uninitialized warnings for all new created uses from __builtin_clear_padding > folding. > > The patch has been bootstrapped and regress tested on both x86 and aarch64. > > Okay for trunk? > > Thanks. > > Qing > > ====================================== > From cf6620005f55d4a1f782332809445c270d22cf86 Mon Sep 17 00:00:00 2001 > From: qing zhao <qing.zhao@oracle.com> > Date: Mon, 21 Feb 2022 16:38:31 +0000 > Subject: [PATCH] Suppress uninitialized warnings for new created uses from > __builtin_clear_padding folding [PR104550] > > __builtin_clear_padding(&object) will clear all the padding bits of the object. > actually, it doesn't involve any use of an user variable. Therefore, users do > not expect any uninitialized warning from it. It's reasonable to suppress > uninitialized warnings for all new created uses from __builtin_clear_padding > folding. > > PR middle-end/104550 > > gcc/ChangeLog: > > * gimple-fold.cc (clear_padding_flush): Suppress warnings for new > created uses. > (clear_padding_emit_loop): Likewise. > (clear_padding_type): Likewise. > (gimple_fold_builtin_clear_padding): Likewise. > > gcc/testsuite/ChangeLog: > > * gcc.dg/auto-init-pr104550-1.c: New test. > * gcc.dg/auto-init-pr104550-2.c: New test. > * gcc.dg/auto-init-pr104550-3.c: New test. > --- > gcc/gimple-fold.cc | 31 +++++++++++++++------ > gcc/testsuite/gcc.dg/auto-init-pr104550-1.c | 10 +++++++ > gcc/testsuite/gcc.dg/auto-init-pr104550-2.c | 11 ++++++++ > gcc/testsuite/gcc.dg/auto-init-pr104550-3.c | 11 ++++++++ > 4 files changed, 55 insertions(+), 8 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-1.c > create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-2.c > create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-3.c > > diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc > index 16f02c2d098..1e18ba3465a 100644 > --- a/gcc/gimple-fold.cc > +++ b/gcc/gimple-fold.cc > @@ -4296,6 +4296,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) > build_int_cst (buf->alias_type, > buf->off + padding_end > - padding_bytes)); > + suppress_warning (dst, OPT_Wuninitialized); > gimple *g = gimple_build_assign (dst, src); > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > @@ -4341,6 +4342,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) > tree dst = build2_loc (buf->loc, MEM_REF, atype, > buf->base, > build_int_cst (buf->alias_type, off)); > + suppress_warning (dst, OPT_Wuninitialized); > gimple *g = gimple_build_assign (dst, src); > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > @@ -4370,6 +4372,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) > atype = build_aligned_type (type, buf->align); > tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, > build_int_cst (buf->alias_type, off)); > + suppress_warning (dst, OPT_Wuninitialized); > tree src; > gimple *g; > if (all_ones > @@ -4420,6 +4423,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) > build_int_cst (buf->alias_type, > buf->off + end > - padding_bytes)); > + suppress_warning (dst, OPT_Wuninitialized); > gimple *g = gimple_build_assign (dst, src); > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > @@ -4620,14 +4624,18 @@ clear_padding_emit_loop (clear_padding_struct *buf, tree type, > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > clear_padding_type (buf, type, buf->sz, for_auto_init); > clear_padding_flush (buf, true); > - g = gimple_build_assign (buf->base, POINTER_PLUS_EXPR, buf->base, > - size_int (buf->sz)); > + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf->base), > + buf->base, size_int (buf->sz)); > + suppress_warning (rhs, OPT_Wuninitialized); > + g = gimple_build_assign (buf->base, rhs); why do we need to suppress warnings on a POINTER_PLUS_EXPR? The use of fold_build2 here is a step backwards btw, I'm not sure whether suppress_warning is properly preserved here. If needed, doesn't suppress_warning (g, OPT_Wuninitialized) work as well, thus suppress the warning on the stmt? > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > g = gimple_build_label (l2); > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > - g = gimple_build_cond (NE_EXPR, buf->base, end, l1, l3); > + tree cond_expr = fold_build2 (NE_EXPR, boolean_type_node, buf->base, end); > + suppress_warning (cond_expr, OPT_Wuninitialized); > + g = gimple_build_cond_from_tree (cond_expr, l1, l3); Likewise. > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > g = gimple_build_label (l3); > @@ -4774,12 +4782,16 @@ clear_padding_type (clear_padding_struct *buf, tree type, > tree elttype = TREE_TYPE (type); > buf->base = create_tmp_var (build_pointer_type (elttype)); > tree end = make_ssa_name (TREE_TYPE (buf->base)); > - gimple *g = gimple_build_assign (buf->base, POINTER_PLUS_EXPR, > - base, size_int (off)); > + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (base), > + base, size_int (off)); > + suppress_warning (rhs, OPT_Wuninitialized); > + gimple *g = gimple_build_assign (buf->base, rhs); Likewise and below - I'd have expected we only need to suppress -Wuninitialized on memory references. Can you clarify? Thanks, Richard. > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > - g = gimple_build_assign (end, POINTER_PLUS_EXPR, buf->base, > - size_int (sz)); > + rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf->base), > + buf->base, size_int (sz)); > + suppress_warning (rhs, OPT_Wuninitialized); > + g = gimple_build_assign (end, rhs); > gimple_set_location (g, buf->loc); > gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > buf->sz = fldsz; > @@ -4933,7 +4945,10 @@ gimple_fold_builtin_clear_padding (gimple_stmt_iterator *gsi) > gimple *g = gimple_build_assign (buf.base, ptr); > gimple_set_location (g, loc); > gsi_insert_before (gsi, g, GSI_SAME_STMT); > - g = gimple_build_assign (end, POINTER_PLUS_EXPR, buf.base, sz); > + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf.base), > + buf.base, sz); > + suppress_warning (rhs, OPT_Wuninitialized); > + g = gimple_build_assign (end, rhs); > gimple_set_location (g, loc); > gsi_insert_before (gsi, g, GSI_SAME_STMT); > buf.sz = eltsz; > diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c > new file mode 100644 > index 00000000000..a08110c3a17 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c > @@ -0,0 +1,10 @@ > +/* PR 104550*/ > +/* { dg-do compile } */ > +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=pattern" } */ > +struct vx_audio_level { > + int has_monitor_level : 1; > +}; > + > +void vx_set_monitor_level() { > + struct vx_audio_level info; /* { dg-bogus "info" "is used uninitialized" } */ > +} > diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c > new file mode 100644 > index 00000000000..2c395b32d32 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c > @@ -0,0 +1,11 @@ > +/* PR 104550 */ > +/* { dg-do compile } */ > +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=zero" } */ > +struct vx_audio_level { > + int has_monitor_level : 1; > +}; > + > +void vx_set_monitor_level() { > + struct vx_audio_level info; > + __builtin_clear_padding (&info); /* { dg-bogus "info" "is used uninitialized" } */ > +} > diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c > new file mode 100644 > index 00000000000..9893e37f12d > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c > @@ -0,0 +1,11 @@ > +/* PR 104550 */ > +/* { dg-do compile } */ > +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=pattern" } */ > +struct vx_audio_level { > + int has_monitor_level : 1; > +}; > + > +void vx_set_monitor_level() { > + struct vx_audio_level info; /* { dg-bogus "info" "is used uninitialized" } */ > + __builtin_clear_padding (&info); /* { dg-bogus "info" "is used uninitialized" } */ > +} >
Hi, Richard, > On Feb 23, 2022, at 1:38 AM, Richard Biener <rguenther@suse.de> wrote: > > On Tue, 22 Feb 2022, Qing Zhao wrote: > >> __builtin_clear_padding(&object) will clear all the padding bits of the object. >> actually, it doesn't involve any use of an user variable. Therefore, users do >> not expect any uninitialized warning from it. It's reasonable to suppress >> uninitialized warnings for all new created uses from __builtin_clear_padding >> folding. >> >> The patch has been bootstrapped and regress tested on both x86 and aarch64. >> >> Okay for trunk? >> >> Thanks. >> >> Qing >> >> ====================================== >> From cf6620005f55d4a1f782332809445c270d22cf86 Mon Sep 17 00:00:00 2001 >> From: qing zhao <qing.zhao@oracle.com> >> Date: Mon, 21 Feb 2022 16:38:31 +0000 >> Subject: [PATCH] Suppress uninitialized warnings for new created uses from >> __builtin_clear_padding folding [PR104550] >> >> __builtin_clear_padding(&object) will clear all the padding bits of the object. >> actually, it doesn't involve any use of an user variable. Therefore, users do >> not expect any uninitialized warning from it. It's reasonable to suppress >> uninitialized warnings for all new created uses from __builtin_clear_padding >> folding. >> >> PR middle-end/104550 >> >> gcc/ChangeLog: >> >> * gimple-fold.cc (clear_padding_flush): Suppress warnings for new >> created uses. >> (clear_padding_emit_loop): Likewise. >> (clear_padding_type): Likewise. >> (gimple_fold_builtin_clear_padding): Likewise. >> >> gcc/testsuite/ChangeLog: >> >> * gcc.dg/auto-init-pr104550-1.c: New test. >> * gcc.dg/auto-init-pr104550-2.c: New test. >> * gcc.dg/auto-init-pr104550-3.c: New test. >> --- >> gcc/gimple-fold.cc | 31 +++++++++++++++------ >> gcc/testsuite/gcc.dg/auto-init-pr104550-1.c | 10 +++++++ >> gcc/testsuite/gcc.dg/auto-init-pr104550-2.c | 11 ++++++++ >> gcc/testsuite/gcc.dg/auto-init-pr104550-3.c | 11 ++++++++ >> 4 files changed, 55 insertions(+), 8 deletions(-) >> create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-1.c >> create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-2.c >> create mode 100644 gcc/testsuite/gcc.dg/auto-init-pr104550-3.c >> >> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc >> index 16f02c2d098..1e18ba3465a 100644 >> --- a/gcc/gimple-fold.cc >> +++ b/gcc/gimple-fold.cc >> @@ -4296,6 +4296,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) >> build_int_cst (buf->alias_type, >> buf->off + padding_end >> - padding_bytes)); >> + suppress_warning (dst, OPT_Wuninitialized); >> gimple *g = gimple_build_assign (dst, src); >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> @@ -4341,6 +4342,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) >> tree dst = build2_loc (buf->loc, MEM_REF, atype, >> buf->base, >> build_int_cst (buf->alias_type, off)); >> + suppress_warning (dst, OPT_Wuninitialized); >> gimple *g = gimple_build_assign (dst, src); >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> @@ -4370,6 +4372,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) >> atype = build_aligned_type (type, buf->align); >> tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, >> build_int_cst (buf->alias_type, off)); >> + suppress_warning (dst, OPT_Wuninitialized); >> tree src; >> gimple *g; >> if (all_ones >> @@ -4420,6 +4423,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) >> build_int_cst (buf->alias_type, >> buf->off + end >> - padding_bytes)); >> + suppress_warning (dst, OPT_Wuninitialized); >> gimple *g = gimple_build_assign (dst, src); >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> @@ -4620,14 +4624,18 @@ clear_padding_emit_loop (clear_padding_struct *buf, tree type, >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> clear_padding_type (buf, type, buf->sz, for_auto_init); >> clear_padding_flush (buf, true); >> - g = gimple_build_assign (buf->base, POINTER_PLUS_EXPR, buf->base, >> - size_int (buf->sz)); >> + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf->base), >> + buf->base, size_int (buf->sz)); >> + suppress_warning (rhs, OPT_Wuninitialized); >> + g = gimple_build_assign (buf->base, rhs); > > why do we need to suppress warnings on a POINTER_PLUS_EXPR? This is the place I was not sure either. Need some discussion… From my understanding, __builtin_clear_padding (&object), does not _use_ any variable, therefore, no uninitialized usage warning should be emitted for it. Therefore, during the folding of __builtin_clear_padding, all the artificial usages of variables that were introduced by the folding should be suppressed from issue uninitialized warning. That’s the basic idea. As a result, I added suppress_warning for all the possible usages of a variable introduced during The folding. So, my question here is: does the new expression “POINTER_PLUS_EXPR (buf->base, buf->size)” Introduce a usage of the “buf->base”? If so, then we should suppress warning for this expression, Right? > The > use of fold_build2 here is a step backwards btw, I'm not sure > whether suppress_warning is properly preserved here. Don’t quite understand here, what’s you mean by “a step backwards”? > If needed, > doesn't suppress_warning (g, OPT_Wuninitialized) work as well, > thus suppress the warning on the stmt? I am not sure here. > >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> g = gimple_build_label (l2); >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> - g = gimple_build_cond (NE_EXPR, buf->base, end, l1, l3); >> + tree cond_expr = fold_build2 (NE_EXPR, boolean_type_node, buf->base, end); >> + suppress_warning (cond_expr, OPT_Wuninitialized); >> + g = gimple_build_cond_from_tree (cond_expr, l1, l3); > > Likewise. > >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> g = gimple_build_label (l3); >> @@ -4774,12 +4782,16 @@ clear_padding_type (clear_padding_struct *buf, tree type, >> tree elttype = TREE_TYPE (type); >> buf->base = create_tmp_var (build_pointer_type (elttype)); >> tree end = make_ssa_name (TREE_TYPE (buf->base)); >> - gimple *g = gimple_build_assign (buf->base, POINTER_PLUS_EXPR, >> - base, size_int (off)); >> + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (base), >> + base, size_int (off)); >> + suppress_warning (rhs, OPT_Wuninitialized); >> + gimple *g = gimple_build_assign (buf->base, rhs); > > Likewise and below - I'd have expected we only need to suppress > -Wuninitialized on memory references. Can you clarify? Based on the current testing case of PR104550, suppress_warning for memory references is enough to resolve the bug, however, if the folding of __builtin_clear_padding might introduce new loops, it will emit POINTER_PLUS_EXPR, I am not sure whether we need to suppress warning for them. Thanks. Qing > > Thanks, > Richard. > >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> - g = gimple_build_assign (end, POINTER_PLUS_EXPR, buf->base, >> - size_int (sz)); >> + rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf->base), >> + buf->base, size_int (sz)); >> + suppress_warning (rhs, OPT_Wuninitialized); >> + g = gimple_build_assign (end, rhs); >> gimple_set_location (g, buf->loc); >> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> buf->sz = fldsz; >> @@ -4933,7 +4945,10 @@ gimple_fold_builtin_clear_padding (gimple_stmt_iterator *gsi) >> gimple *g = gimple_build_assign (buf.base, ptr); >> gimple_set_location (g, loc); >> gsi_insert_before (gsi, g, GSI_SAME_STMT); >> - g = gimple_build_assign (end, POINTER_PLUS_EXPR, buf.base, sz); >> + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf.base), >> + buf.base, sz); >> + suppress_warning (rhs, OPT_Wuninitialized); >> + g = gimple_build_assign (end, rhs); >> gimple_set_location (g, loc); >> gsi_insert_before (gsi, g, GSI_SAME_STMT); >> buf.sz = eltsz; >> diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c >> new file mode 100644 >> index 00000000000..a08110c3a17 >> --- /dev/null >> +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c >> @@ -0,0 +1,10 @@ >> +/* PR 104550*/ >> +/* { dg-do compile } */ >> +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=pattern" } */ >> +struct vx_audio_level { >> + int has_monitor_level : 1; >> +}; >> + >> +void vx_set_monitor_level() { >> + struct vx_audio_level info; /* { dg-bogus "info" "is used uninitialized" } */ >> +} >> diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c >> new file mode 100644 >> index 00000000000..2c395b32d32 >> --- /dev/null >> +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c >> @@ -0,0 +1,11 @@ >> +/* PR 104550 */ >> +/* { dg-do compile } */ >> +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=zero" } */ >> +struct vx_audio_level { >> + int has_monitor_level : 1; >> +}; >> + >> +void vx_set_monitor_level() { >> + struct vx_audio_level info; >> + __builtin_clear_padding (&info); /* { dg-bogus "info" "is used uninitialized" } */ >> +} >> diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c >> new file mode 100644 >> index 00000000000..9893e37f12d >> --- /dev/null >> +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c >> @@ -0,0 +1,11 @@ >> +/* PR 104550 */ >> +/* { dg-do compile } */ >> +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=pattern" } */ >> +struct vx_audio_level { >> + int has_monitor_level : 1; >> +}; >> + >> +void vx_set_monitor_level() { >> + struct vx_audio_level info; /* { dg-bogus "info" "is used uninitialized" } */ >> + __builtin_clear_padding (&info); /* { dg-bogus "info" "is used uninitialized" } */ >> +} >> > > -- > Richard Biener <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
On Wed, Feb 23, 2022 at 05:33:57PM +0000, Qing Zhao wrote: > From my understanding, __builtin_clear_padding (&object), does not _use_ any variable, > therefore, no uninitialized usage warning should be emitted for it. __builtin_clear_padding (&object) sometimes expands to roughly: *(int *)((char *)&object + 32) = 0; etc., in that case it shouldn't be suppressed in any way, it doesn't read anything, only stores. Or at other times it is: *(int *)((char *)&object + 32) &= 0xfec7dab1; etc., in that case it reads bytes from the object which can be uninitialized, we mask some bits off and store. It is similar to what object.bitfld = 3; expands to, but usually only after the uninit pass. Though, we have the optimize_bit_field_compare optimization, that is done very early and I wonder what uninit does about that. Perhaps it ignores BIT_FIELD_REFs, I'd need to check that. Anyway, if we want to disable uninit warnings for __builtin_clear_padding, we should do that with suppress_warning on the read stmts that load a byte (or more adjacent ones) before they are masked off and stored again, so that we don't warn about that. Jakub
> On Feb 23, 2022, at 11:49 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Wed, Feb 23, 2022 at 05:33:57PM +0000, Qing Zhao wrote: >> From my understanding, __builtin_clear_padding (&object), does not _use_ any variable, >> therefore, no uninitialized usage warning should be emitted for it. > > __builtin_clear_padding (&object) > sometimes expands to roughly: > *(int *)((char *)&object + 32) = 0; > etc., in that case it shouldn't be suppressed in any way, it doesn't read > anything, only stores. > Or at other times it is: > *(int *)((char *)&object + 32) &= 0xfec7dab1; > etc., in that case it reads bytes from the object which can be > uninitialized, we mask some bits off and store. Okay, I see. So, only the MEM_REF that will be used to read first should be suppressed warning. Then there is only one (out of 4) MEM_REF should be suppressed warning, that’s the following one (line 4371 and then line 4382): 4371 tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, 4372 build_int_cst (buf->alias_type, off)); 4373 tree src; 4374 gimple *g; 4375 if (all_ones 4376 && nonzero_first == start 4377 && nonzero_last == start + eltsz) 4378 src = build_zero_cst (type); 4379 else 4380 { 4381 src = make_ssa_name (type); 4382 g = gimple_build_assign (src, unshare_expr (dst)); 4383 gimple_set_location (g, buf->loc); 4384 gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); 4385 tree mask = native_interpret_expr (type, 4386 buf->buf + i + start, 4387 eltsz); 4388 gcc_assert (mask && TREE_CODE (mask) == INTEGER_CST); 4389 mask = fold_build1 (BIT_NOT_EXPR, type, mask); 4390 tree src_masked = make_ssa_name (type); 4391 g = gimple_build_assign (src_masked, BIT_AND_EXPR, 4392 src, mask); 4393 gimple_set_location (g, buf->loc); 4394 gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); 4395 src = src_masked; 4396 } 4397 g = gimple_build_assign (dst, src); All the other 3 MEM_REFs are not read. So, we can just exclude them from suppressing warning, right? Another question, for the above MEM_REF, should I suppress warning for line 4371 “dst”? Or shall I Suppress warning for line 4382 (for the “unshared_expr(dst)”)? I think that we should suppress warning for the latter, i.e “unshared_expr(dst)” at line 4382, right? > > It is similar to what object.bitfld = 3; expands to, > but usually only after the uninit pass. Though, we have the > optimize_bit_field_compare optimization, that is done very early > and I wonder what uninit does about that. Perhaps it ignores > BIT_FIELD_REFs, I'd need to check that. Yes, I see that uninitialized warning specially handles BIT_INSERT_EXPR as: (tree-ssa-uninit.cc) 573 /* Do not warn if the result of the access is then used for 574 a BIT_INSERT_EXPR. */ 575 if (lhs && TREE_CODE (lhs) == SSA_NAME) 576 FOR_EACH_IMM_USE_FAST (luse_p, liter, lhs) 577 { 578 gimple *use_stmt = USE_STMT (luse_p); 579 /* BIT_INSERT_EXPR first operand should not be considered 580 a use for the purpose of uninit warnings. */ > > Anyway, if we want to disable uninit warnings for __builtin_clear_padding, > we should do that with suppress_warning on the read stmts that load > a byte (or more adjacent ones) before they are masked off and stored again, > so that we don't warn about that. IN addition to this read stmts, shall we suppress warnings for the following: /* Emit a runtime loop: for (; buf.base != end; buf.base += sz) __builtin_clear_padding (buf.base); */ static void clear_padding_emit_loop (clear_padding_struct *buf, tree type, tree end, bool for_auto_init) { i.e, should we suppress warnings for the above “buf.base != end”, “buf.base += sz”? No need to suppress warning for them since they just read the address of the object, not the object itself? thanks. Qing > > Jakub >
On Wed, 23 Feb 2022, Qing Zhao wrote: > > > > On Feb 23, 2022, at 11:49 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > > > On Wed, Feb 23, 2022 at 05:33:57PM +0000, Qing Zhao wrote: > >> From my understanding, __builtin_clear_padding (&object), does not _use_ any variable, > >> therefore, no uninitialized usage warning should be emitted for it. > > > > __builtin_clear_padding (&object) > > sometimes expands to roughly: > > *(int *)((char *)&object + 32) = 0; > > etc., in that case it shouldn't be suppressed in any way, it doesn't read > > anything, only stores. > > Or at other times it is: > > *(int *)((char *)&object + 32) &= 0xfec7dab1; > > etc., in that case it reads bytes from the object which can be > > uninitialized, we mask some bits off and store. > > Okay, I see. > So, only the MEM_REF that will be used to read first should be suppressed warning. Then there is only one (out of 4) MEM_REF > should be suppressed warning, that’s the following one (line 4371 and then line 4382): > > 4371 tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, > 4372 build_int_cst (buf->alias_type, off)); > 4373 tree src; > 4374 gimple *g; > 4375 if (all_ones > 4376 && nonzero_first == start > 4377 && nonzero_last == start + eltsz) > 4378 src = build_zero_cst (type); > 4379 else > 4380 { > 4381 src = make_ssa_name (type); > 4382 g = gimple_build_assign (src, unshare_expr (dst)); > 4383 gimple_set_location (g, buf->loc); > 4384 gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > 4385 tree mask = native_interpret_expr (type, > 4386 buf->buf + i + start, > 4387 eltsz); > 4388 gcc_assert (mask && TREE_CODE (mask) == INTEGER_CST); > 4389 mask = fold_build1 (BIT_NOT_EXPR, type, mask); > 4390 tree src_masked = make_ssa_name (type); > 4391 g = gimple_build_assign (src_masked, BIT_AND_EXPR, > 4392 src, mask); > 4393 gimple_set_location (g, buf->loc); > 4394 gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); > 4395 src = src_masked; > 4396 } > 4397 g = gimple_build_assign (dst, src); > > > All the other 3 MEM_REFs are not read. So, we can just exclude them from suppressing warning, right? > Another question, for the above MEM_REF, should I suppress warning for line 4371 “dst”? Or shall I > Suppress warning for line 4382 (for the “unshared_expr(dst)”)? > > I think that we should suppress warning for the latter, i.e “unshared_expr(dst)” at line 4382, right? Yes, the one that's put into the GIMPLE stmt. > > > > It is similar to what object.bitfld = 3; expands to, > > but usually only after the uninit pass. Though, we have the > > optimize_bit_field_compare optimization, that is done very early > > and I wonder what uninit does about that. Perhaps it ignores > > BIT_FIELD_REFs, I'd need to check that. > > Yes, I see that uninitialized warning specially handles BIT_INSERT_EXPR as: (tree-ssa-uninit.cc) > > 573 /* Do not warn if the result of the access is then used for > 574 a BIT_INSERT_EXPR. */ > 575 if (lhs && TREE_CODE (lhs) == SSA_NAME) > 576 FOR_EACH_IMM_USE_FAST (luse_p, liter, lhs) > 577 { > 578 gimple *use_stmt = USE_STMT (luse_p); > 579 /* BIT_INSERT_EXPR first operand should not be considered > 580 a use for the purpose of uninit warnings. */ That follows the COMPLEX_EXPR handling I think. > > > > Anyway, if we want to disable uninit warnings for __builtin_clear_padding, > > we should do that with suppress_warning on the read stmts that load > > a byte (or more adjacent ones) before they are masked off and stored again, > > so that we don't warn about that. > > IN addition to this read stmts, shall we suppress warnings for the following: > > /* Emit a runtime loop: > for (; buf.base != end; buf.base += sz) > __builtin_clear_padding (buf.base); */ > > static void > clear_padding_emit_loop (clear_padding_struct *buf, tree type, > tree end, bool for_auto_init) > { > > i.e, should we suppress warnings for the above “buf.base != end”, “buf.base += sz”? > > No need to suppress warning for them since they just read the address of the object, not the object itself? No need to supporess those indeed. Richard.
> On Feb 24, 2022, at 2:46 AM, Richard Biener <rguenther@suse.de> wrote: > > On Wed, 23 Feb 2022, Qing Zhao wrote: > >> >> >>> On Feb 23, 2022, at 11:49 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>> >>> On Wed, Feb 23, 2022 at 05:33:57PM +0000, Qing Zhao wrote: >>>> From my understanding, __builtin_clear_padding (&object), does not _use_ any variable, >>>> therefore, no uninitialized usage warning should be emitted for it. >>> >>> __builtin_clear_padding (&object) >>> sometimes expands to roughly: >>> *(int *)((char *)&object + 32) = 0; >>> etc., in that case it shouldn't be suppressed in any way, it doesn't read >>> anything, only stores. >>> Or at other times it is: >>> *(int *)((char *)&object + 32) &= 0xfec7dab1; >>> etc., in that case it reads bytes from the object which can be >>> uninitialized, we mask some bits off and store. >> >> Okay, I see. >> So, only the MEM_REF that will be used to read first should be suppressed warning. Then there is only one (out of 4) MEM_REF >> should be suppressed warning, that’s the following one (line 4371 and then line 4382): >> >> 4371 tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, >> 4372 build_int_cst (buf->alias_type, off)); >> 4373 tree src; >> 4374 gimple *g; >> 4375 if (all_ones >> 4376 && nonzero_first == start >> 4377 && nonzero_last == start + eltsz) >> 4378 src = build_zero_cst (type); >> 4379 else >> 4380 { >> 4381 src = make_ssa_name (type); >> 4382 g = gimple_build_assign (src, unshare_expr (dst)); >> 4383 gimple_set_location (g, buf->loc); >> 4384 gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> 4385 tree mask = native_interpret_expr (type, >> 4386 buf->buf + i + start, >> 4387 eltsz); >> 4388 gcc_assert (mask && TREE_CODE (mask) == INTEGER_CST); >> 4389 mask = fold_build1 (BIT_NOT_EXPR, type, mask); >> 4390 tree src_masked = make_ssa_name (type); >> 4391 g = gimple_build_assign (src_masked, BIT_AND_EXPR, >> 4392 src, mask); >> 4393 gimple_set_location (g, buf->loc); >> 4394 gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); >> 4395 src = src_masked; >> 4396 } >> 4397 g = gimple_build_assign (dst, src); >> >> >> All the other 3 MEM_REFs are not read. So, we can just exclude them from suppressing warning, right? >> Another question, for the above MEM_REF, should I suppress warning for line 4371 “dst”? Or shall I >> Suppress warning for line 4382 (for the “unshared_expr(dst)”)? >> >> I think that we should suppress warning for the latter, i.e “unshared_expr(dst)” at line 4382, right? > > Yes, the one that's put into the GIMPLE stmt. Okay. > >>> >>> It is similar to what object.bitfld = 3; expands to, >>> but usually only after the uninit pass. Though, we have the >>> optimize_bit_field_compare optimization, that is done very early >>> and I wonder what uninit does about that. Perhaps it ignores >>> BIT_FIELD_REFs, I'd need to check that. >> >> Yes, I see that uninitialized warning specially handles BIT_INSERT_EXPR as: (tree-ssa-uninit.cc) >> >> 573 /* Do not warn if the result of the access is then used for >> 574 a BIT_INSERT_EXPR. */ >> 575 if (lhs && TREE_CODE (lhs) == SSA_NAME) >> 576 FOR_EACH_IMM_USE_FAST (luse_p, liter, lhs) >> 577 { >> 578 gimple *use_stmt = USE_STMT (luse_p); >> 579 /* BIT_INSERT_EXPR first operand should not be considered >> 580 a use for the purpose of uninit warnings. */ > > That follows the COMPLEX_EXPR handling I think. > >>> >>> Anyway, if we want to disable uninit warnings for __builtin_clear_padding, >>> we should do that with suppress_warning on the read stmts that load >>> a byte (or more adjacent ones) before they are masked off and stored again, >>> so that we don't warn about that. >> >> IN addition to this read stmts, shall we suppress warnings for the following: >> >> /* Emit a runtime loop: >> for (; buf.base != end; buf.base += sz) >> __builtin_clear_padding (buf.base); */ >> >> static void >> clear_padding_emit_loop (clear_padding_struct *buf, tree type, >> tree end, bool for_auto_init) >> { >> >> i.e, should we suppress warnings for the above “buf.base != end”, “buf.base += sz”? >> >> No need to suppress warning for them since they just read the address of the object, not the object itself? > > No need to supporess those indeed. agreed. thanks. Will send out the new version soon. Qing > > Richard.
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc index 16f02c2d098..1e18ba3465a 100644 --- a/gcc/gimple-fold.cc +++ b/gcc/gimple-fold.cc @@ -4296,6 +4296,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) build_int_cst (buf->alias_type, buf->off + padding_end - padding_bytes)); + suppress_warning (dst, OPT_Wuninitialized); gimple *g = gimple_build_assign (dst, src); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); @@ -4341,6 +4342,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, build_int_cst (buf->alias_type, off)); + suppress_warning (dst, OPT_Wuninitialized); gimple *g = gimple_build_assign (dst, src); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); @@ -4370,6 +4372,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) atype = build_aligned_type (type, buf->align); tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base, build_int_cst (buf->alias_type, off)); + suppress_warning (dst, OPT_Wuninitialized); tree src; gimple *g; if (all_ones @@ -4420,6 +4423,7 @@ clear_padding_flush (clear_padding_struct *buf, bool full) build_int_cst (buf->alias_type, buf->off + end - padding_bytes)); + suppress_warning (dst, OPT_Wuninitialized); gimple *g = gimple_build_assign (dst, src); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); @@ -4620,14 +4624,18 @@ clear_padding_emit_loop (clear_padding_struct *buf, tree type, gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); clear_padding_type (buf, type, buf->sz, for_auto_init); clear_padding_flush (buf, true); - g = gimple_build_assign (buf->base, POINTER_PLUS_EXPR, buf->base, - size_int (buf->sz)); + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf->base), + buf->base, size_int (buf->sz)); + suppress_warning (rhs, OPT_Wuninitialized); + g = gimple_build_assign (buf->base, rhs); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); g = gimple_build_label (l2); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); - g = gimple_build_cond (NE_EXPR, buf->base, end, l1, l3); + tree cond_expr = fold_build2 (NE_EXPR, boolean_type_node, buf->base, end); + suppress_warning (cond_expr, OPT_Wuninitialized); + g = gimple_build_cond_from_tree (cond_expr, l1, l3); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); g = gimple_build_label (l3); @@ -4774,12 +4782,16 @@ clear_padding_type (clear_padding_struct *buf, tree type, tree elttype = TREE_TYPE (type); buf->base = create_tmp_var (build_pointer_type (elttype)); tree end = make_ssa_name (TREE_TYPE (buf->base)); - gimple *g = gimple_build_assign (buf->base, POINTER_PLUS_EXPR, - base, size_int (off)); + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (base), + base, size_int (off)); + suppress_warning (rhs, OPT_Wuninitialized); + gimple *g = gimple_build_assign (buf->base, rhs); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); - g = gimple_build_assign (end, POINTER_PLUS_EXPR, buf->base, - size_int (sz)); + rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf->base), + buf->base, size_int (sz)); + suppress_warning (rhs, OPT_Wuninitialized); + g = gimple_build_assign (end, rhs); gimple_set_location (g, buf->loc); gsi_insert_before (buf->gsi, g, GSI_SAME_STMT); buf->sz = fldsz; @@ -4933,7 +4945,10 @@ gimple_fold_builtin_clear_padding (gimple_stmt_iterator *gsi) gimple *g = gimple_build_assign (buf.base, ptr); gimple_set_location (g, loc); gsi_insert_before (gsi, g, GSI_SAME_STMT); - g = gimple_build_assign (end, POINTER_PLUS_EXPR, buf.base, sz); + tree rhs = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (buf.base), + buf.base, sz); + suppress_warning (rhs, OPT_Wuninitialized); + g = gimple_build_assign (end, rhs); gimple_set_location (g, loc); gsi_insert_before (gsi, g, GSI_SAME_STMT); buf.sz = eltsz; diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c new file mode 100644 index 00000000000..a08110c3a17 --- /dev/null +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-1.c @@ -0,0 +1,10 @@ +/* PR 104550*/ +/* { dg-do compile } */ +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=pattern" } */ +struct vx_audio_level { + int has_monitor_level : 1; +}; + +void vx_set_monitor_level() { + struct vx_audio_level info; /* { dg-bogus "info" "is used uninitialized" } */ +} diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c new file mode 100644 index 00000000000..2c395b32d32 --- /dev/null +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-2.c @@ -0,0 +1,11 @@ +/* PR 104550 */ +/* { dg-do compile } */ +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=zero" } */ +struct vx_audio_level { + int has_monitor_level : 1; +}; + +void vx_set_monitor_level() { + struct vx_audio_level info; + __builtin_clear_padding (&info); /* { dg-bogus "info" "is used uninitialized" } */ +} diff --git a/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c b/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c new file mode 100644 index 00000000000..9893e37f12d --- /dev/null +++ b/gcc/testsuite/gcc.dg/auto-init-pr104550-3.c @@ -0,0 +1,11 @@ +/* PR 104550 */ +/* { dg-do compile } */ +/* { dg-options "-O -Wuninitialized -ftrivial-auto-var-init=pattern" } */ +struct vx_audio_level { + int has_monitor_level : 1; +}; + +void vx_set_monitor_level() { + struct vx_audio_level info; /* { dg-bogus "info" "is used uninitialized" } */ + __builtin_clear_padding (&info); /* { dg-bogus "info" "is used uninitialized" } */ +}