From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62038 invoked by alias); 24 Oct 2017 13:24:35 -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 61196 invoked by uid 89); 24 Oct 2017 13:24:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f174.google.com Received: from mail-wr0-f174.google.com (HELO mail-wr0-f174.google.com) (209.85.128.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Oct 2017 13:24:27 +0000 Received: by mail-wr0-f174.google.com with SMTP id j15so8515272wre.8 for ; Tue, 24 Oct 2017 06:24:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=vv55XcyaOnFZUrQvVhhsVIEwUKNHfLIUbo7DhB/PLUE=; b=W9OuaNeiV5ImKFX6sWT9OPbde73fLK3gLwJgqAhr1UjZIZRTuZyNutoksdZ1rhQmPt e66wG3PqL9eMh4pxnMgAh/5CABhjz5fetiNRvrVxwcjz9T1npEFUaiF+JoZCxM+rkb1w Q7j6rsnw2YUHtbEMkc2ZQdN8pYx0a3XYk72sGq8SPjPcM8BA1IGDEax1HuLBYlgo/TIS fWEecqK1oobUyvWYuqEg77MDuUwUP56ApztBVACz0Gk+Z6w3XQChTR4FRYzaa9bAcduq eO0OsGDSEYOc+dtgTkuRCZxNFQy14YmeMTw9WYwM7w68N5GFNv2BFBmPnWJPgld57taV 9GBw== X-Gm-Message-State: AMCzsaUv3oSMQ5wb8GkcUW9aq4rQFu5r6UF1bNwq26bit0Qia4jY+N1n IzmfRNaCN/nEmY5GTJq9s9/fFDyDMbM= X-Google-Smtp-Source: ABhQp+TP39EWytvtlt8goy788jQib0uGQML0xFiN4LNXKTepDegJS0pmjHWtNVJtEZtdoNNne0LCFw== X-Received: by 10.223.172.242 with SMTP id o105mr13537714wrc.242.1508851463988; Tue, 24 Oct 2017 06:24:23 -0700 (PDT) Received: from localhost (92.40.248.184.threembb.co.uk. [92.40.248.184]) by smtp.gmail.com with ESMTPSA id c17sm368530wrg.26.2017.10.24.06.24.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 06:24:23 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Eric Botcazou , GCC Patches , richard.sandiford@linaro.org Cc: Eric Botcazou , GCC Patches Subject: Re: [000/nnn] poly_int: representation of runtime offsets and sizes References: <871sltvm7r.fsf@linaro.org> <4728974.295PUQgt1k@polaris> <87o9owq35v.fsf@linaro.org> <10524871.8B8OuvVQlb@polaris> <87fua8pz6v.fsf@linaro.org> <87bmkwpv8j.fsf@linaro.org> Date: Tue, 24 Oct 2017 13:30:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 24 Oct 2017 15:07:30 +0200") Message-ID: <877evkptkr.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-10/txt/msg01696.txt.bz2 Richard Biener writes: > 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 don't think it's templates specifically. We end up with something like: int f (unsigned int x, const int y) { return x != y; } int g (unsigned int x) { return f (x, 0); } which generates a warning too. > I'd be fine with must_eq_p and may_eq_0. OK, I'll switch to that if there are no objections. Thanks, Richard