From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92032 invoked by alias); 31 May 2019 00:26:02 -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 92019 invoked by uid 89); 31 May 2019 00:26:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=business X-HELO: mail-ot1-f49.google.com Received: from mail-ot1-f49.google.com (HELO mail-ot1-f49.google.com) (209.85.210.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 May 2019 00:26:01 +0000 Received: by mail-ot1-f49.google.com with SMTP id i2so6502840otr.9 for ; Thu, 30 May 2019 17:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=p/DFNgrrvP2jd6KM78fAusHR/XJsVGempbkrBcA2h6A=; b=jrauvfc6NPOTdmjRe1suowNehlMsqAdUBN6ZBAPeAHHtjxXztI7qscf9BpkD6KKEl7 wqltR7mF2Y8TDY5B0zpqibOw/lpm3YLiNo5ZSIJ5cNEo4zob5w2zyEW46mREe12bOte/ XsqTRk+FHO7H2b1+8EgtCuwwRpDS+qKzfwNcCwZuN7gUAXXgnc4IlUd4ea5ZWRm9h5u2 hs1Jfi1Fv4jGkvpYtkXikL86LCcjRmq6WXFQa56o0X9ccYrDjzXTBbu66RMa/iqia1Fv qDaHQRdEJi1SHvHUWkXDyjmYbYucVHDTnpRQqWHop3vEOuxrsDq/FFpp4Fdb86FMK+Lv TPFw== Return-Path: Received: from [192.168.0.41] (97-118-125-210.hlrn.qwest.net. [97.118.125.210]) by smtp.gmail.com with ESMTPSA id p188sm1608816oia.14.2019.05.30.17.25.57 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 30 May 2019 17:25:58 -0700 (PDT) Subject: Re: value_range_base::{non_zero_p, set_zero, set_non_zero} To: Aldy Hernandez , gcc-patches References: From: Martin Sebor Message-ID: <5b4d0a49-693d-457d-b635-f6445706bd9f@gmail.com> Date: Fri, 31 May 2019 00:59: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg02075.txt.bz2 On 5/30/19 12:58 AM, Aldy Hernandez wrote: > Hi. > > We have zero_p in the API, but we don't have non_zero_p.  Instead we use > a non-API function range_is_nonnull.  I've fixed this. > > I have also gotten rid of the duplicity of using the non-API > range_is_null in favor of value_range_base::zero_p(). > > Furthermore, there's value_range*::set_null and > value_range*::set_nonnull().  It's inconsistent to use null/nonnull as > well as zero/non_zero throughout.  I've moved everything to *zero. With the -Wformat-diag cleanup still fresh in my memory, I can't help but point out that the GCC spelling convention calls for "nonzero" vs "non-zero" or "non zero". Naming the function set_nonzero() would be in line with both the convention and established practice (over 2000 instances) and set_non_zero would not be (only 22 instances of non_zero in GCC sources). This, of course, is in contrast to things like bit-field and built-in where the convention calls for the hyphen but where in code we seem to prefer "bitfield" nonetheless ;-) (Names like get_bit_field_ref_def and bit_field_size being the exceptions). Martin > > Finally, it seems to me that the derived value_range versions of > set_*zero/null are a bit confusing in that they clear equivalences > behind the scenes.  There's no intuitive reason why setting a range of > [0,0] versus [5,10] should clear equivalences.  I've made the > equivalence nuking explicit in the handful of places where we do this, > and thus reduced the need for separate value_range versions. > > I believe with these changes, as well as the pending intersect patch, > we've cleaned up the remaining value_range uses where we actually wanted > to use value_range_base.  Or at least the remaining "value_range tem" > business. > > OK? > > Aldy