From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94020 invoked by alias); 24 Oct 2017 13:07:44 -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 94010 invoked by uid 89); 24 Oct 2017 13:07:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 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= X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Oct 2017 13:07:33 +0000 Received: by mail-wm0-f48.google.com with SMTP id q124so15624621wmb.0 for ; Tue, 24 Oct 2017 06:07:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IU16rpH2+bUqGl2t3HaR3sgnlFyVckomHp49lRsLr70=; b=Sj0JT0E+RofH0usYRnFsWGffgrSvI/OyQfWgM6sXtE5aoSlJFwnDXRxntzGG/c3Hka 2YP9Rrg5gd6EWPf4oUhiU0XZWusqAqchyUTtek32KboptAMHsDzhkBhm/BRRf+zI6M1q LiIKYc7oOEm09lfcFebeuDafZ4Za1/KGf5bgxO740r1PAWwdEvz8F4BERy2jzBVgQF8J xZJLlp02anpl5P4bBJ+lxAbE/JxHXYj/oLorZadpzvX1mMNM70jDFhxdpvKJG3GF5X9m bw5De8CB19soslyVMWxIyqFx2B2g462gbJd3mkET1SpyBxC1vp9bGLcPCiJiFyyUr1JQ tgEA== X-Gm-Message-State: AMCzsaU3wbivghzUs03JPV1+ra3k70Hc34EaHHSA9MCKIjl93k1wnsbe 6oJi+8ZZjvLczaI2RTP/0C21WGrTcUxS4RTIVs0= X-Google-Smtp-Source: ABhQp+SsO2osDmZHRnNshmK1+bkXgUor759qToGRT5IE8TkMEJd9pkeCvrgpCoWPBRU6vB0AGp4MV0s+n0MUWn2Hmbw= X-Received: by 10.80.137.91 with SMTP id f27mr19685818edf.18.1508850450846; Tue, 24 Oct 2017 06:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Tue, 24 Oct 2017 06:07:30 -0700 (PDT) In-Reply-To: <87bmkwpv8j.fsf@linaro.org> References: <871sltvm7r.fsf@linaro.org> <4728974.295PUQgt1k@polaris> <87o9owq35v.fsf@linaro.org> <10524871.8B8OuvVQlb@polaris> <87fua8pz6v.fsf@linaro.org> <87bmkwpv8j.fsf@linaro.org> From: Richard Biener Date: Tue, 24 Oct 2017 13:18:00 -0000 Message-ID: Subject: Re: [000/nnn] poly_int: representation of runtime offsets and sizes To: Richard Biener , Eric Botcazou , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg01693.txt.bz2 On Tue, Oct 24, 2017 at 2:48 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Tue, Oct 24, 2017 at 1:23 PM, Richard Sandiford >> wrote: >>> Eric Botcazou writes: >>>>> Yeah. E.g. for ==, the two options would be: >>>>> >>>>> a) must_eq (a, b) -> a == b >>>>> must_ne (a, b) -> a != b >>>>> >>>>> which has the weird property that (a == b) != (!(a != b)) >>>>> >>>>> b) must_eq (a, b) -> a == b >>>>> may_ne (a, b) -> a != b >>>>> >>>>> which has the weird property that a can be equal to b when a != b >>>> >>>> Yes, a) was the one I had in mind, i.e. the traditional operators are >>>> the must >>>> variants and you use an outer ! in order to express the may. Of course this >>>> would require a bit of discipline but, on the other hand, if most of >>>> the cases >>>> fall in the must category, that could be less ugly. >>> >>> I just think that discipline is going to be hard to maintain in practice, >>> since it's so natural to assume (a == b || a != b) == true. With the >>> may/must approach, static type checking forces the issue. >>> >>>>> Sorry about that. It's the best I could come up with without losing >>>>> the may/must distinction. >>>> >>>> Which variant is known_zero though? Must or may? >>> >>> must. maybe_nonzero is the may version. >> >> Can you rename known_zero to must_be_zero then? > > That'd be OK with me. > > Another alternative I wondered about was must_eq_0 / may_ne_0. > >> What's wrong with must_eq (X, 0) / may_eq (X, 0) btw? > > must_eq (X, 0) generated a warning if X is unsigned, so sometimes you'd > need must_eq (X, 0) and sometimes must_eq (X, 0U). Is that because they are templates? Maybe providing a partial specialization would help? I'd be fine with must_eq_p and may_eq_0. Richard. > Having a specific > function seemed cleaner, especially in routines that were polymorphic > in X. > > Or we could suppress warnings by forcibly converting the input. > Sometimes the warnings are useful though. > > Thanks, > Richard