From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40945 invoked by alias); 3 Jul 2017 12:37:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 40933 invoked by uid 89); 3 Jul 2017 12:37:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=kidding, sell X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Jul 2017 12:37:53 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AB908AC6D; Mon, 3 Jul 2017 12:37:50 +0000 (UTC) Date: Mon, 03 Jul 2017 12:37:00 -0000 From: Richard Biener To: Marc Glisse cc: gcc-patches@gcc.gnu.org, Jakub Jelinek , =?ISO-8859-15?Q?Martin_Li=A8ka?= Subject: Re: [RFC PATCH] Fix pointer diff (was: -fsanitize=pointer-overflow support (PR sanitizer/80998)) In-Reply-To: Message-ID: References: <20170619182515.GA2123@tucnak> <20170620081348.GE2123@tucnak> <20170621144001.GR2123@tucnak> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2017-07/txt/msg00093.txt.bz2 On Sat, 1 Jul 2017, Marc Glisse wrote: > On Thu, 22 Jun 2017, Richard Biener wrote: > > > On Thu, 22 Jun 2017, Marc Glisse wrote: > > > > > On Thu, 22 Jun 2017, Richard Biener wrote: > > > > > > > > If we consider pointers as unsigned, with a subtraction that has a > > > > > signed > > > > > result with the constraint that overflow is undefined, we cannot model > > > > > that > > > > > optimally with just the usual signed/unsigned operations, so I am in > > > > > favor > > > > > of > > > > > POINTER_DIFF, at least in the long run (together with having a signed > > > > > second > > > > > argument for POINTER_PLUS, etc). For 64-bit platforms it might have > > > > > been > > > > > easier to declare that the upper half (3/4 ?) of the address space > > > > > doesn't > > > > > exist... > > > > > > > > I repeatedly thought of POINTER_DIFF_EXPR but adding such a basic tree > > > > code is quite a big job. > > > > > > Yes :-( > > > It is probably not realistic to introduce it just to avoid a couple > > > regressions while fixing a bug. > > > > > > > So we'd have POINTER_DIFF_EXPR take two pointer typed args and produce > > > > ptrdiff_t. What's the advantage of having this? > > > > > > It represents q-p with one statement instead of 3 (long)q-(long)p or 4 > > > (long)((ulong)q-(ulong)p). It allows us to stay in the pointer world, so > > > (q-p)>0 is equivalent to p > > what (undefined) overflow means for pointers. > > > > > > Of course it is hard to know in advance if that's significant or > > > negligible, maybe size_t finds its way in too many places anyway. > > > > As with all those experiments ... > > > > Well, if I would sell this as a consultant to somebody I'd estimate > > 3 man months for this work which realistically means you have to > > start now otherwise you won't make it this stage 1. > > I wrote a quick prototype to see what the fallout would look like. > Surprisingly, it actually passes bootstrap+testsuite on ppc64el with all > languages with no regression. Sure, it is probably not a complete > migration, there are likely a few places still converting to ptrdiff_t > to perform a regular subtraction, but this seems to indicate that the > work isn't as bad as using a signed type in pointer_plus_expr for > instance. The fold_binary_loc hunk looks dangerous (it'll generate MINUS_EXPR from POINTER_MINUS_EXPR in some cases I guess). The tree code needs documenting in tree.def and generic.texi. Otherwise ok(*). Thanks, Richard. (*) ok, just kidding -- or maybe not