From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) by sourceware.org (Postfix) with ESMTPS id B539E3858D35 for ; Mon, 22 Nov 2021 10:12:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B539E3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.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 1CED84619AB; Mon, 22 Nov 2021 10:12:06 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AE581460FEE; Mon, 22 Nov 2021 10:12:04 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.114.196.213 (trex/6.4.3); Mon, 22 Nov 2021 10:12:05 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Stretch-Whistle: 1a7f8e364b42d6fc_1637575925857_3274119956 X-MC-Loop-Signature: 1637575925857:3681702324 X-MC-Ingress-Time: 1637575925857 Received: from [192.168.1.174] (unknown [1.186.224.140]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4HyNNf6YPCz1WX; Mon, 22 Nov 2021 02:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1637575924; bh=zl+DR5q+WhRbsnp4L0ZihfeO3fk=; h=Date:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=ADCkag8uF0c0f6aeHpLRI3/78NMGl1+W+ihHT+9n45+/K7DIpzyLG34kv698RLIgL betkd5/o6c4vtzNcb6vpdCB4YQQrF2xnOTcN7z8IW73Np0UY9weIxUMB3lTwMPbC1D nYGEW1sg9b7yq51Rt46cObqvBgUC8dmgj0HMu3zE= Message-ID: Date: Mon, 22 Nov 2021 15:41:57 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH 03/10] tree-object-size: Use tree instead of HOST_WIDE_INT Content-Language: en-US From: Siddhesh Poyarekar To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20211109190137.1107736-1-siddhesh@gotplt.org> <20211109190137.1107736-4-siddhesh@gotplt.org> <20211119170639.GT2646553@tucnak> <7915f97c-54ca-1d23-506a-bc916620c12a@gotplt.org> In-Reply-To: <7915f97c-54ca-1d23-506a-bc916620c12a@gotplt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3029.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 10:12:09 -0000 On 11/20/21 00:31, Siddhesh Poyarekar wrote: >> This doesn't match what the code did and I'm surprised if it works at >> all. >> TREE_OPERAND (pt_var, 1), while it is an INTEGER_CST or POLY_INT_CST, >> has in its type encoded the type for aliasing, so the type is some >> pointer >> type.  Performing size_binop etc. on such values can misbehave, the code >> assumes that it is sizetype or at least some integral type compatible >> with >> it.Also, mem_ref_offset is signed and offset_int has bigger precision >> than pointers on the target such that it can be always signed.  So >> e.g. if MEM_REF's second operand is bigger or equal than half of the >> address space, in the old code it would appear to be negative, wi::sub >> would >> result in a value bigger than sz.  Not really sure right now if that is >> exactly how we want to treat it, would be nice to try some testcase. > > Let me try coming up with a test case for it. > So I played around a bit with this. Basically: char buf[8]; __SIZE_TYPE__ test (void) { char *p = &buf[0x90000004]; return __builtin_object_size (p + 2, 0); } when built with -m32 returns 0x70000002 but on 64-bit, returns 0 as expected. of course, with subscript as 0x9000000000000004, 64-bit gives 0x7000000000000002 as the result. With the tree conversion, this is at least partly taken care of since offset larger than size, to the extent that it fits into sizetype, returns a size of zero. So in the above example, the size returned is zero in both -m32 as well as -m64. Likewise for negative offset, i.e. &buf[-4]; the old code returns 10 while with trees it returns 0, which seems correct to me since it is an underflow. It's only partly taken care of because, e.g. char *p = &buf[0x100000004]; ends up truncating the offset, returning object size of 2. This however is an unrelated problem; it's the folding of offsets that is responsible for this since it ends up truncating the offset to shwi bounds. Perhaps there's an opportunity in get_addr_base_and_unit_offset to warn of overflow if offset goes above pointer precision before truncating it. So for this patch, may I simply ensure that offset is converted to sizetype and keep everything else the same? it appears to demonstrate better behaviour than the older code. I'll also add these tests. Thanks, Siddhesh