From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) by sourceware.org (Postfix) with ESMTPS id 999E83857404 for ; Wed, 5 May 2021 14:41:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 999E83857404 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 145EdVhS073587; Wed, 5 May 2021 14:41:46 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 38begja161-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 05 May 2021 14:41:46 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 145EfI4C078524; Wed, 5 May 2021 14:41:45 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 38bebtks0s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 05 May 2021 14:41:45 +0000 Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 145Efhhv020050; Wed, 5 May 2021 14:41:44 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 07:41:43 -0700 Content-Type: text/plain; charset=utf-8 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 From: Qing Zhao In-Reply-To: Date: Wed, 5 May 2021 09:41:42 -0500 Cc: Richard Biener , Kees Cook , Gcc-patches Qing Zhao via Content-Transfer-Encoding: quoted-printable Message-Id: <0A50A5F3-9F17-4F4D-85A8-F59FF31BD58E@oracle.com> References: <0CE28536-176B-44E1-BDC6-3942739B829C@oracle.com> To: Richard Sandiford 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 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105050107 X-Proofpoint-GUID: BefQvOQnopF7Qs_NkQSS8woeARY2aAkv X-Proofpoint-ORIG-GUID: BefQvOQnopF7Qs_NkQSS8woeARY2aAkv X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9975 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 spamscore=0 adultscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105050107 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 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 14:41:51 -0000 Hi, Richard,=20 During the change for the 2nd version based on your previous comments, I = have the following questions need your help: >=20 >> + sra_stats.subtree_deferred_init++; >> + } >> + else if (access->grp_to_be_debug_replaced) >> + { >> + /* FIXME, this part might have some issue. */ >> + tree drhs =3D build_debug_ref_for_model (loc, agg, >> + access->offset - = top_offset, >> + access); >> + gdebug *ds =3D gimple_build_debug_bind (get_access_replacement = (access), >> + drhs, gsi_stmt (*gsi)); >> + gsi_insert_before (gsi, ds, GSI_SAME_STMT); >=20 > Would be good to fix the FIXME :-) >=20 > I guess the thing we need to decide here is whether = -ftrivial-auto-var-init > should affect debug-only constructs too. If it doesn't, exmaining = removed > components in a debugger might show uninitialised values in cases = where > the user was expecting initialised ones. There would be no security > concern, but it might be surprising. >=20 > I think in principle the DRHS can contain a call to DEFERRED_INIT. > Doing that would probably require further handling elsewhere though. Right now, what I did is: else if (lhs_access->grp_to_be_debug_replaced) { tree lhs_drepl =3D get_access_replacement (lhs_access); tree init_type_node =3D build_int_cst (integer_type_node, (int) init_type); tree call =3D build_call_expr_internal_loc (UNKNOWN_LOCATION, IFN_DEFERRED_INIT, TREE_TYPE (lhs_drepl), 2, lhs_drepl, init_type_node); gdebug *ds =3D gimple_build_debug_bind (lhs_drepl, call, gsi_stmt (*gsi)); gsi_insert_before (gsi, ds, GSI_SAME_STMT); } Is the above matching what you suggested? What do you mean by =E2=80=9Cfurther handling elsewhere=E2=80=9D? >=20 >> + is better even for pattern initialization. */ >> + return build_int_cstu (type, largevalue); >=20 > I've no objection to that choice for booleans, but: booleans in some > languages (like Ada) can have multibit precision. If we want booleans > to be zero then it would probably be better to treat them as a = separate > case and just use build_zero_cst (type) for them. >=20 > Also, the above won't work correctly for 128-bit integers: it will > zero-initialize the upper half. It would probably be better to use > wi::from_buffer to construct the integer instead. You mean using wi::from_buffer to construct all the integer type = (including 64-bit, 32-bit, etc.)? I read the corresponding source codes related to =E2=80=9Cwi::from_buffer=E2= =80=9D, but still not very clear On how to use it for my purpose, =46rom my current understanding, I should use it like the following: " unsigned char *ptr =3D =E2=80=9C0xAAAAAAAAAAAAAAAA=E2=80=9D; Int total_bytes =3D GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (type)); wide_int result =3D wi::from_buffer (ptr, total_bytes); return wide_int_to_tree (type, result); =E2=80=9C Is the above correct for INTEGER type? thanks. Qing