From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57282 invoked by alias); 25 Oct 2017 10:19:42 -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 57269 invoked by uid 89); 25 Oct 2017 10:19:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Oct 2017 10:19:40 +0000 Received: by mail-wm0-f42.google.com with SMTP id r68so886293wmr.3 for ; Wed, 25 Oct 2017 03:19:39 -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=vLpsG26vEhKQ40UmzFi+AQHJA+7+0nJmwuZyyUZUIFA=; b=cX3E9CeUXI5bMvld4PydfJ1QmORwZu0UALbERMAXH8UucCnwi+V9y7Q/xdybSmcNJD QnTxvuRHQh/tG6OCV1Q9dW2HRryJPRrrUACsbjOyd37hNj9M0sRlB/fOyk9ExdiMwc3g uff1hmeSsReCp7vcv3kBOsCdMJEXWkiZmBg4YWuwlv7jAEPAn4bVfxT5PGTjxeDcZSJ1 8j9Pd7xuCFLFY5I99nHFksLwwVJLXa7eF3EqRphyteq7PBspmYBfFZGlBufWly4GJF2z UEmV3k7gUdZjVpjO+tNIvdZD3Hz0QvUSIgQmawXaSwe1zcBgRY2OyrIFN/Op+rGtdAYW K1Dg== X-Gm-Message-State: AMCzsaV0v6fslDoX9QrsnMuirZHaGGwYXXPZil5YKeWx/yKwK/LZCWnn NBN0nIZomHet/GWgBq2nYGdAuXTqypwnBgB4xoo= X-Google-Smtp-Source: ABhQp+RcrrSBqraYJgg4mLu6mpPaggufTjdMIW7l6UxXTBv4V+2U+leJjmhnhwyvazMNlIgdmtRQr8b2zZN8F/Frocs= X-Received: by 10.80.158.194 with SMTP id a60mr20184397edf.182.1508926778032; Wed, 25 Oct 2017 03:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Wed, 25 Oct 2017 03:19:37 -0700 (PDT) In-Reply-To: <877evkptkr.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> <877evkptkr.fsf@linaro.org> From: Richard Biener Date: Wed, 25 Oct 2017 10:27: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/msg01793.txt.bz2 On Tue, Oct 24, 2017 at 3:24 PM, Richard Sandiford wrote: > 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. Hum. But then we still warn for must_eq_p (x, 1), no? So why does int f (unsigned int x) { return x != 0; } not warn? Probably because of promotion of the arg. Shouldn't we then simply never have a may/must_*_p (T1, T2) with T1 and T2 being not compatible? That is, force promotion rules on them with template magic? Richard. > Thanks, > Richard