From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id BE8D93858034 for ; Mon, 22 Nov 2021 12:00:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE8D93858034 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=gotplt.org Received: from hamster.birch.relay.mailchannels.net ([23.83.209.80]:47698) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mp800-0002BP-N9 for gcc-patches@gcc.gnu.org; Mon, 22 Nov 2021 07:00:43 -0500 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 904E7620E03; Mon, 22 Nov 2021 12:00:30 +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 02EAE620427; Mon, 22 Nov 2021 12:00:29 +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.97.65.138 (trex/6.4.3); Mon, 22 Nov 2021 12:00:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Rock-Troubled: 55dfc4460d3a032e_1637582430283_2971611691 X-MC-Loop-Signature: 1637582430283:730412328 X-MC-Ingress-Time: 1637582430282 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 4HyQnm0jFVz1WX; Mon, 22 Nov 2021 04:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1637582429; bh=U9/r/t1ZZINc2G+5cVRHZypEpa0=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=hWNqulO+lHfSUm1f8V+wU7jg6BSO+I0lbSMjRwBuN/9eoBkfAzKHcLpfG3408Q2k6 UZwLFkzuhhcy2miSiMU3wjNKIlGnfNRiXZTe2pB4ubWsjTVeUY/hFvONIbHLfU2YVa e8fMHfz7yhx1ch967lW95K67WyTLys0tugizLv8g= Message-ID: <1468e98c-7834-b6eb-593d-53bfa1430f83@gotplt.org> Date: Mon, 22 Nov 2021 17:30:22 +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 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> <20211122103150.GL2646553@tucnak> From: Siddhesh Poyarekar In-Reply-To: <20211122103150.GL2646553@tucnak> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=23.83.209.80; envelope-from=siddhesh@gotplt.org; helo=hamster.birch.relay.mailchannels.net X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.097, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-3028.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_FAIL, SPF_HELO_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 12:00:45 -0000 On 11/22/21 16:01, Jakub Jelinek wrote: > On Mon, Nov 22, 2021 at 03:41:57PM +0530, Siddhesh Poyarekar wrote: >> 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. > > That is one case, I think when the base is a ADDR_EXPR VAR_DECL, offsets > larger than half of the address space will be UB, though of course the > question is what __bos should return for that because it wants to prevent > UB exploiting. > > Another case is where the base is some pointer, something like > &MEM_REF [ptr, -16].a > etc., where the MEM_REF offset negative makes a lot of sense, > there could be > ptr = &var + 32; > earlier etc. > That gives us to the general question on what to do with POINTER_PLUS_EXPR > if the offset is constant but "negative" (as it is sizetype, it is never > negative, but usually we treat it or should treat it as signed in the end). > If the offset is "negative", for e.g. __bos 0/1 one option is to use a > conservative maximum, i.e. subtract the offset from the value (make it even > larger, of course make sure it doesn't wrap around). Another one would be > to consider also __bos 2 in that case, if the negation of the offset is > bigger than __bos 2, then the pointer points to before the start of the > object and we could return 0. So I've got patch 10/10, which handles dynamic (and consequently negative) offsets. It basically computes a "whole size", which then gives the extent to which a negative offset is valid, making the estimates a bit more precise. I didn't do it for static object sizes because I didn't have time then, but I could add a patch 11/10 if the idea sounds OK to you. Siddhesh