From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90934 invoked by alias); 31 Jan 2020 08:03:15 -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 90925 invoked by uid 89); 31 Jan 2020 08:03:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Received:Fri, pnvi, PNVI X-HELO: mail-lf1-f42.google.com Received: from mail-lf1-f42.google.com (HELO mail-lf1-f42.google.com) (209.85.167.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Jan 2020 08:03:13 +0000 Received: by mail-lf1-f42.google.com with SMTP id r14so4216342lfm.5 for ; Fri, 31 Jan 2020 00:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IZgkeMV9ja5jITBGTJtCuVfTZg+qtRkqQUfVRBKF/QQ=; b=Gm7tupWurud6q2RuRec3AaxlSIcaQa4JDPpx2dX69qOsJT/+CxB5d1QTZosei1ExkD 9FjwvNKMyir5rncfDhUAhwHFOD0Bkp+STotf+1BhErLWT5Yfbg2bMrylHgjauipQtuVa +1fCi7mJ3va7LSS5OybNf9U/wDRf/Gcl1OrGbFDeKZF17PrARuiLSgYHsa8PofuzHAUv dEBntZL7yUQ9uSN01Z7DRqDf5saymTNh+jTC9UkpRvBYfM0yPUl7GOfsZlZ97UglJt/4 MZdsxwJPfE/91nxIn5Fwuqi1w9UcSK95SG3LuhD8FQ0gS0ssfGAW4nP4fpGWjyCoMVJ0 wJRQ== MIME-Version: 1.0 References: <0ea4d9e9-8358-78e3-3153-0eda111d20b7@gmail.com> <1579823158.4442.3.camel@med.uni-goettingen.de> <1580172878.9104.1.camel@med.uni-goettingen.de> <1580214291.2690.8.camel@med.uni-goettingen.de> <1580306413.6601.1.camel@med.uni-goettingen.de> <1580393395.6784.2.camel@med.uni-goettingen.de> <1580404176.6646.2.camel@med.uni-goettingen.de> In-Reply-To: <1580404176.6646.2.camel@med.uni-goettingen.de> From: Richard Biener Date: Fri, 31 Jan 2020 09:31:00 -0000 Message-ID: Subject: Re: [PATCH] doc: clarify the situation with pointer arithmetic To: "Uecker, Martin" Cc: "matz@suse.de" , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg02056.txt.bz2 On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin wrote: > > Am Donnerstag, den 30.01.2020, 16:50 +0000 schrieb Michael Matz: > > Hi, > > > > On Thu, 30 Jan 2020, Uecker, Martin wrote: > > > > > > guarantees face serious implementation difficulties I think > > > > so the only alternative to PVNI (which I think is implementable > > > > but at a optimization opportunity cost) is one that makes > > > > two pointers with the same value always have the same > > > > provenance (and otherwise make the behavior undefined). > > > > > > This would need to come with precise rules about > > > when the occurance of two such pointers is UB, > > > e.g. comparisons of such pointers, or that > > > two such pointers are cast to int in the same > > > execution. > > > > > > The mere existance of such pointers should be > > > quite common and should not already be UB. > > > > > > But I am uncomfortable with the idea that > > > comparison of pointers is always allowed except > > > for some special case which then is UB. This > > > might cause are and very difficult to find bugs. > > > > As Richi said, the comparison itself wouldn't be UB, all comparisons would > > be allowed. But _if_ the pointers compare equal, they must have same (or > > overlapping) provenance (i.e. when they have not, then _that_ is UB). > > Sorry, I still don't get it. In the following example, > > int a[1]; > int b[1]; > > it is often the case that &a[1] and &b[0] compare equal > because they have the same address but the pointer > have different provenance. > > Or does there need to be an actual evaluation of a comparison > operations? In this case, I do not see the difference to what > I said. I guess I wanted to say that if you do if (&a[1] == &b[0]) if (&a[1] != &b[0]) abort (); then the abort might happen. I'm using the term "undefined behavior" here. So whenever you create a value based on two pointers with the same value and different provenance you invoke undefined behavior. That allows the compiler to optimize int *q, *r; if (q == r) *r = 1; into if (q == r) *q = 1; which it is currently not allowed to do because of that dread one-after-the object equality compare, not because of PNVI, but similar cases obviously can be constructed with integers (and make our live difficult as we're tracking provenance through integers). Compilers fundamentally work with value-equivalences, the above example shows we may not. That's IMHO a defect in the standard. Richard. > > Best, > Martin > > > > > > Others proposed to make the result of the comparison unspecified, > > > > > but I think this does not help. > > > > > > > > Indeed. It's not unspecified, it's known to evaluate to false. I > > > > think there's existing wording in the standard that allows it to > > > > evaluate to true for pointers one-after-the-object, that would need to > > > > be changed of course. > > > > > > The problem is that if the comparison if not optimized > > > and the pointers have the same address, then it would > > > evaluate to true at run-time. If I understand correctly, > > > you somehow want to make this case be UB, but I haven't > > > quite understood how (if it is not the comparison of such > > > pointers that invokes UB). > > > > By saying something like "if two pointers compare equal they must have the > > same provenance, otherwise the behaviour is undefined". > > > (I don't know if this definition would or would not help with the problems > > PVNI poses to compilers). > > > > > > Ciao, > > Michael.