From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85912 invoked by alias); 14 Dec 2018 00:10:17 -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 85820 invoked by uid 89); 14 Dec 2018 00:10:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=additions X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Dec 2018 00:10:11 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXalh-00059E-HO for gcc-patches@gcc.gnu.org; Thu, 13 Dec 2018 18:51:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41326) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gXalh-00055s-9n for gcc-patches@gcc.gnu.org; Thu, 13 Dec 2018 18:51:49 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E3F833086249; Thu, 13 Dec 2018 23:51:17 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-24.rdu2.redhat.com [10.10.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2520A26373; Thu, 13 Dec 2018 23:51:16 +0000 (UTC) Subject: Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367) To: Jakub Jelinek Cc: Richard Biener , gcc-patches@gcc.gnu.org References: <20181206064535.GN12380@tucnak> <4111f316-2383-d9ff-c5db-0b5f9475e9c7@redhat.com> <20181206203252.GX12380@tucnak> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <14722f16-9d2a-34c6-d8a5-8320e335016c@redhat.com> Date: Fri, 14 Dec 2018 00:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20181206203252.GX12380@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01003.txt.bz2 On 12/6/18 1:32 PM, Jakub Jelinek wrote: >> For -fno-delete-null-pointer-checks ISTM >> we should indicate "we don't know anything about the result" of such an >> operation. > > There are cases where we still know something. The largest valid object > that can be supported is half of the address space, so without pointer > wrapping, positive additions to the pointer shouldn't wrap around and yield > NULL, negative ones can. With -fwrapv-pointers anything can happen, sure, > the only case handled in that case is &[ptr + 0] if ptr is ~[0, 0] then > &[ptr + 0] is also ~[0, 0]. Yea. I just didn't figure those were worth worrying about. jeff