From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101101 invoked by alias); 18 Apr 2019 12:51:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 101092 invoked by uid 89); 18 Apr 2019 12:51:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=day X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Apr 2019 12:51:02 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 74402307D786; Thu, 18 Apr 2019 12:51:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.40.205.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1513F60BF7; Thu, 18 Apr 2019 12:51:00 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x3ICowM3023576; Thu, 18 Apr 2019 14:50:58 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x3ICoug0023575; Thu, 18 Apr 2019 14:50:56 +0200 Date: Thu, 18 Apr 2019 12:51:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: "Uecker, Martin" , "Peter.Sewell@cl.cam.ac.uk" , "gcc@gcc.gnu.org" , "law@redhat.com" , "cl-c-memory-object-model@lists.cam.ac.uk" Subject: Re: C provenance semantics proposal Message-ID: <20190418125056.GC21066@tucnak> Reply-To: Jakub Jelinek References: <1555502021.4884.1.camel@med.uni-goettingen.de> <1555505779.4884.4.camel@med.uni-goettingen.de> <1555510321.4884.7.camel@med.uni-goettingen.de> <1555590011.12545.3.camel@med.uni-goettingen.de> <20190418124717.GB21066@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190418124717.GB21066@tucnak> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00203.txt.bz2 On Thu, Apr 18, 2019 at 02:47:18PM +0200, Jakub Jelinek wrote: > On Thu, Apr 18, 2019 at 02:42:22PM +0200, Richard Biener wrote: > > > 1.) Compilers do not use conditional equivalences for > > > optimizations of pointers (or only when additional > > > conditions apply which make it safe) > > > > > > 2.) We make pointer comparison between a pointer > > > and a one-after pointer of a different object > > > undefined behaviour. > > > > Yes please! OTOH GCC transforms > > (uintptr_t)&a != (uintptr_t)(&b+1) > > into &a != &b + 1 (for equality compares) and then > > I think we don't. It was http://gcc.gnu.org/PR88775, but we haven't applied > those changes, because we don't consider the point to start of one object > vs. pointer to end of another one case in pointer comparisons (but do > consider it in integral comparisons). That said, in RTL we really don't differentiate between pointers and integers and we'll need to do something about that one day. Jakub