From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rusty.tulip.relay.mailchannels.net (rusty.tulip.relay.mailchannels.net [23.83.218.252]) by sourceware.org (Postfix) with ESMTPS id 897193858C2D for ; Tue, 24 Oct 2023 21:04:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 897193858C2D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 897193858C2D Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.218.252 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698181455; cv=pass; b=ahoLjY5bxsE0L8C4rW2f0d623zGrsOWL31uRDh6y+Y1qDQve69tiDeHSZvcmcNP9wrtUYXvdHDM0q7g9glqRfrbqyeW7T0LDnID1SaX8sOyN3kmqkXD3oglFsEkkfewbWD2i1SM2nkugSi3o1hZ+hglYswNkRmAAftwkaW6ntgE= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698181455; c=relaxed/simple; bh=8W6zNqYs+6DbuLnIB8X3xWDYkzYUS3XRPhkOeHald3I=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=js0oejTfjxCgaw6nM0Ouby7ijEJWzgtmFC79pB/TRlHuv6cAU8lGlBnT3f2DlbRCMe6WL1Uf6YafvJ00A+W6xZ84ixMgchlHb5NJm2vaoSIuYXcdoa9vuh5iIuY6sJtVxQRqTFlV2/69RRDGRctH1z4lF1peUg/Qc+OQXg/DoRg= ARC-Authentication-Results: i=2; server2.sourceware.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 991AE8414BB; Tue, 24 Oct 2023 21:04:11 +0000 (UTC) Received: from pdx1-sub0-mail-a202.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7776A842726; Tue, 24 Oct 2023 21:03:52 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1698181445; a=rsa-sha256; cv=none; b=FdyFzTbaGUNK9isIB8OC/KN8oY+Tmsx1jSroFRlOHdCvRBjCNVGVhZpD0ht0v6ukpR1wYC kgS2brvISWIQxd00WsREWZ4XDlTqGZ6V+YCC4F6LnOBkHhyX4NP6i0APf3PPvxHCMrIaak xZftKmAfcWUhipj25nnKrFdt/BFmk3FOXjykRp9fouUXC34KekGPK95DSg6WNb13uGtAMO S/sFPyt60UL4X+Z68dNNbCFYa4fm7bVtwgXYRRYLg2Kv8CJo+B8GSsWqrGvBZHYTxlnEcZ Su3uuc7leD9FJP1lhIk0k03tyImgFds9fEVKp54MkTRZAKNBGYGFV+bR5Rf0Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1698181445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+l1OGqd5ISfiRFzzBzeRA7vvaPfRkXFczCgEUbFa9U4=; b=ENUrl1pPFzoaNWnHMIF0+8hc31v9P5W89D5+TpMtQekQJg3OfOeO7+LjHxs1u+qvwWl0FJ TeFc8wUxHHPGeKzoXPEkxPXJ3gB8yrCEg4fepKqQ9fC8j5S0bLiY5cGbWvHvQ8Al/d9B+R mgZBPo+HM9Bk0JPyRxdJeIWbXTsKvXSwwPEAckhK6hVUuOaXo8pb7CaAhgcOrYMkvYz7J/ Zsyh/3SFd3Po7MQAJ2YINUf2rZXSbcvlNuT35d/hf5Yq9VHd/VJeUuaz0osiSUil1YeBMR NtBd+qz+jlNiRnVaDM3GTfNm5XQ9cdDcOfDT0u+tVWrl0ZYyDJYtOorGJKx6GA== ARC-Authentication-Results: i=1; rspamd-79d8cddc67-ckllj; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Cooing-Abaft: 16745d013993a765_1698181446157_688155585 X-MC-Loop-Signature: 1698181446157:2793994591 X-MC-Ingress-Time: 1698181446157 Received: from pdx1-sub0-mail-a202.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.117.92.245 (trex/6.9.2); Tue, 24 Oct 2023 21:04:05 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a202.dreamhost.com (Postfix) with ESMTPSA id 4SFPg1759RzBW; Tue, 24 Oct 2023 14:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1698181422; bh=+l1OGqd5ISfiRFzzBzeRA7vvaPfRkXFczCgEUbFa9U4=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=mUNlpEjkkiGCFcTu5KLSFwjWTBjbhaiAW5rMWid2IBEUVGRCDUfXx6deXu1evLTya eRQAsjZKD2cUMFNVXe1RNj9TOsLbu2o/cQN9+dmxCe7h2eeqMyj1meQfXcn0AaM3jw Fa/vKfXA/b5Xb0+cWbwkGqNMwxjkX6kgiDWQa9fgs+Mekd94vTgQ3xFibOW1FpT91I cW5FyyN79dfb9wOIiWFGuyjlR6QE/pvCDdwrPxle4pip2Rbz50CzwM0nuuImR3k4yR laGlXpYyqI4H4TfIq0wL4aTqVJIqZCBaY53bUH2vAQvvDzpX+RPPZUq4v+0drcekgZ gnqcoYVEZXgXg== Message-ID: Date: Tue, 24 Oct 2023 17:03:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) Content-Language: en-US To: Qing Zhao , Richard Biener Cc: Martin Uecker , Joseph Myers , Jakub Jelinek , gcc Patches , kees Cook , "isanbard@gmail.com" References: <9DDD0677-BFE7-4733-8C11-0FA8B3C25569@oracle.com> <283B5497-52BD-47D4-BC08-0982AB6740CA@oracle.com> <53e8ed5778d0e908d224d940ddc3d99575b83dd3.camel@tugraz.at> <168fea24-844e-4d1a-9361-afb6332b4f11@gotplt.org> <8C548B97-BD81-4EBB-A59C-F7E6E0A3C4F7@oracle.com> <92426898-afa7-47f7-9aab-5f2114eb826a@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3030.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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 List-Id: On 2023-10-24 16:30, Qing Zhao wrote: > Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”, therefore, the call to __bdos is Not in the same routine as the instantiation of the object, As a result, the TYPE info and the attached counted_by info of the object can NOT be USED by the __bdos call. > But __bos/__bdos are barely useful without optimization; you need a minimum of -O1. You're right that if the call is never inlined then we don't care because the __bdos call does not get expanded to obj->size. However, the point of situation 2 is that the TYPE info cannot be used by the __bdos call *only for a while* (i.e. until the call gets inlined) and that window is an opportunity for the reordering/DSE to break things. Thanks. Sid