From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40836 invoked by alias); 31 Oct 2017 20:20:09 -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 40476 invoked by uid 89); 31 Oct 2017 20:20:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2411, surprising, att, claim X-HELO: mail-oi0-f46.google.com Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com) (209.85.218.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Oct 2017 20:20:08 +0000 Received: by mail-oi0-f46.google.com with SMTP id g125so323186oib.12 for ; Tue, 31 Oct 2017 13:20:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UlHcfwNPR+PLTzumNzWCtMk0fuYHkDSdBa/r8Zx9r5U=; b=ePN7pJJttZAO6phWU2vd1avqQ/Mwe8sRYyaElt9FUaRAyIcaYwkrAxaWw8SzQ7wMqM OCSAv9oKLjr0Qu0p/JqxbDknMCaOhcPEhWAgG2ohXOQSEK/eIkihasTkeNxqq5XX1BdK dOoy165tz35VF5zMmWVNoU6qnkDTVNXkwIBkWnQC/dCiZBZ6g9tMNMdjSzzjXqzHb8Iw xTIXdurkM7k9gQ0LVGHOpdNr0Q4ByvLpyhMSvopOO80UEJS/xYYuCcY6qp78QeN0Z3JO mR5VJfvb+poJ1CBOMEDu0Trw89h0pjChR+WZd+27/WtClGn8+RSnVZuaE3BRZjk/566Z AJnQ== X-Gm-Message-State: AMCzsaVz2K6olp+edBRjyIWi2LSEYsMkFXHDfMCiz6k3hOEhAf+VRQaR tm87BDMDjApY956JylZWmKI= X-Google-Smtp-Source: ABhQp+QTi0EwfD7ITgK6r8CFz7xSiQM6aY/o8mv5qJD4gxtRa8ItEakT2SG+MePDyzzvils6+xcjpA== X-Received: by 10.157.60.212 with SMTP id t20mr1853797otf.137.1509481206570; Tue, 31 Oct 2017 13:20:06 -0700 (PDT) Received: from [172.20.33.7] ([67.201.107.102]) by smtp.gmail.com with ESMTPSA id 8sm1028131otu.19.2017.10.31.13.20.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 13:20:05 -0700 (PDT) Subject: Re: [006/nnn] poly_int: tree constants To: Trevor Saunders Cc: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <878tg1u7cl.fsf@linaro.org> <877evi3oeh.fsf@linaro.org> <8737662tlp.fsf@linaro.org> <2840a6a6-f80c-ca8f-aab2-2729ac598bf6@gmail.com> <87tvyl23v7.fsf@linaro.org> <86b2e46b-4cb5-57cb-63db-aacc2cb41c47@gmail.com> <87lgjx108l.fsf@linaro.org> <20171030031434.736b6gkt3ponwcgu@ball> From: Martin Sebor Message-ID: <4dc8177e-7c9c-1f30-588b-3dc99cbe19c6@gmail.com> Date: Tue, 31 Oct 2017 20:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171030031434.736b6gkt3ponwcgu@ball> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg02370.txt.bz2 On 10/29/2017 09:14 PM, Trevor Saunders wrote: > On Sun, Oct 29, 2017 at 10:25:38AM -0600, Martin Sebor wrote: >> On 10/27/2017 02:08 AM, Richard Sandiford wrote: >>> Martin Sebor writes: >>>> On 10/26/2017 11:52 AM, Richard Sandiford wrote: >>>>> Martin Sebor writes: >>>>>> For offset_int the default precision is 128-bits. Making that >>>>>> the default also for wide_int should be unsurprising. >>>>> >>>>> I think it'd be surprising. offset_int should always be used in >>>>> preference to wide_int if the precision is known to be 128 bits >>>>> in advance, and there doesn't seem any reason to prefer the >>>>> precision of offset_int over widest_int, HOST_WIDE_INT or int. >>>>> >>>>> We would end up with: >>>>> >>>>> wide_int >>>>> f (const wide_int &y) >>>>> { >>>>> wide_int x; >>>>> x += y; >>>>> return x; >>>>> } >>>>> >>>>> being valid if y happens to have 128 bits as well, and a runtime error >>>>> otherwise. >>>> >>>> Surely that would be far better than the undefined behavior we >>>> have today. >>> >>> I disagree. People shouldn't rely on the above behaviour because >>> it's never useful. >> >> Well, yes, but the main point of my feedback on the poly_int default >> ctor (and the ctor of the extended_tree class, and the existing wide >> int classes) is that it makes them easy to misuse. That they're not >> meant to be [mis]used like that isn't an answer. > > I think Richard's point is different from saying don't misuse it. I > think its that 0 initializing is also always a bug, and the user needs > to choosesome initialization to follow the default ctor in either case. Initializing offset_int to zero isn't a bug and there are examples of it in GCC sources. Some of those are now being replaced with those of poly_int xxx = 0. Here's one example from [015/nnn] poly_int: ao_ref and vn_reference_op_t: @@ -1365,8 +1369,8 @@ indirect_refs_may_alias_p (tree ref1 ATT refs_may_alias_p_1 (ao_ref *ref1, ao_ref *ref2, bool tbaa_p) { tree base1, base2; - HOST_WIDE_INT offset1 = 0, offset2 = 0; - HOST_WIDE_INT max_size1 = -1, max_size2 = -1; + poly_int64 offset1 = 0, offset2 = 0; + poly_int64 max_size1 = -1, max_size2 = -1; I'm not suggesting these be changed to avoid the explicit initialization. But I show this to disprove the claim above. Clearly, zero initialization is valid and useful. Martin