From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by sourceware.org (Postfix) with ESMTPS id 16C6A3858001 for ; Wed, 5 May 2021 17:29:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 16C6A3858001 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 145HOLf9173367; Wed, 5 May 2021 17:29:11 GMT Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 38bemjjktq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 05 May 2021 17:29:11 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 145HQJ09134639; Wed, 5 May 2021 17:29:11 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 38bebjc3r5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 05 May 2021 17:29:10 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 145HT966026779; Wed, 5 May 2021 17:29:09 GMT Received: from dhcp-10-154-100-82.vpn.oracle.com (/10.154.100.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2021 10:29:09 -0700 From: Qing Zhao Message-Id: <039556DA-C209-41A7-9833-150CA485E982@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc Date: Wed, 5 May 2021 12:29:08 -0500 In-Reply-To: <0DDDEAB4-AA58-4F98-9526-8F63AEAC3D3D@oracle.com> Cc: Richard Biener , Gcc-patches Qing Zhao via , Kees Cook To: Richard Sandiford References: <0CE28536-176B-44E1-BDC6-3942739B829C@oracle.com> <0DDDEAB4-AA58-4F98-9526-8F63AEAC3D3D@oracle.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9975 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105050120 X-Proofpoint-ORIG-GUID: E8VkabwGkTD617qRai3AZ9NaCJxgabw1 X-Proofpoint-GUID: E8VkabwGkTD617qRai3AZ9NaCJxgabw1 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9975 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 phishscore=0 impostorscore=0 priorityscore=1501 spamscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 mlxscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105050120 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 17:29:18 -0000 >=20 >>=20 >>> @@ -11950,6 +12088,72 @@ lower_bound_in_type (tree outer, tree = inner) >>> } >>> } >>>=20 >>> +/* Returns true when the given TYPE has padding inside it. >>> + return false otherwise. */ >>> +bool >>> +type_has_padding (tree type) >>=20 >> Would it be possible to reuse __builtin_clear_padding here? >=20 > Not sure, where can I get more details on __builtin_clear_padding? I = can study a little bit more on this to make sure this. After some study, my understanding is, the call to = __builtin_clear_padding is expanded during gimplification phase. =20 And there is no __bultin_clear_padding expanding during rtx expanding = phase. Is the above understanding correct?=20 If so, for -ftrivial-auto-var-init, padding initialization should be = done both in gimplification phase and rtx expanding phase.=20 And since the __builtin_clear_padding might not be good for rtx = expanding, reusing __builtin_clear_padding might not work. Let me know if I misunderstand something. Qing >>=20