From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101216 invoked by alias); 25 Oct 2017 11:26:46 -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 101206 invoked by uid 89); 25 Oct 2017 11:26:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f54.google.com Received: from mail-wm0-f54.google.com (HELO mail-wm0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Oct 2017 11:26:44 +0000 Received: by mail-wm0-f54.google.com with SMTP id u138so1238026wmu.4 for ; Wed, 25 Oct 2017 04:26:44 -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=gDvWU7UdvWsumFG2SxEx9mSGA40wfG3kUjL/Bc/Uuho=; b=ULR0NYSFlTKQnH4U45NxKL6oRUyY9+G9PHMyqrXpcptj9QXJShJD98z+WRYbLUl94S YuP3NCcKSIxXYX37GEGliuzuZlLvOVSOAbheZ1eIbH+mRHrHXR/ax1fwpyr6m+i1Qhrd 9FOsGO8c5Vd2m2qk2lGpl+jJE7YDU5UQb4UOX1TPCSzpnTQJ8m0NSP8gN0Z4AfT4luZr twthU0Rk+mvE6N4w3H1FjmdRDUnoP8Zk/ObqXMvM6oBgOyTM78HIpwB8nKVTFtptuXZD qDPQ17XT6360WQYu6RJbfa9kKggiXoTGZM9f/qza2WSDXO2Z9P4QU5+V9kZM3A3n4SJR +s0Q== X-Gm-Message-State: AMCzsaVPSjI4xhtep4fJWEqPTF9xSx1BJOp5gA6lVKAyH3N2xt7QhxEg 6mcZPHcsaJfD0yuRDBXpf0jZbL+ah+E= X-Google-Smtp-Source: ABhQp+Qc7u5aOJF6lolktKAmyM8eIVTSxKasyJ+uj7vxc+WUbg7AT3R/B7bdGE0/KG3f8VKlnnWK3g== X-Received: by 10.28.216.5 with SMTP id p5mr1578516wmg.155.1508930802351; Wed, 25 Oct 2017 04:26:42 -0700 (PDT) Received: from localhost (92.40.249.210.threembb.co.uk. [92.40.249.210]) by smtp.gmail.com with ESMTPSA id 31sm2068641wrm.0.2017.10.25.04.26.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Oct 2017 04:26:41 -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> <877evkptkr.fsf@linaro.org> Date: Wed, 25 Oct 2017 11:39:00 -0000 In-Reply-To: (Richard Biener's message of "Wed, 25 Oct 2017 12:19:37 +0200") Message-ID: <87she7tqmo.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/msg01800.txt.bz2 Richard Biener writes: > 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? Yeah. The patch also had a known_one and known_all_ones for those two (fairly) common cases. For other values the patches just add "U" where necessary. If you think it would be better to use U consistently and not have the helpers, then I'm happy to do that instead. > So why does > > int f (unsigned int x) > { > return x != 0; > } > > not warn? Probably because of promotion of the arg. [Jakub's already answered this part.] > 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? This was what I meant by: Or we could suppress warnings by forcibly converting the input. Sometimes the warnings are useful though. We already do this kind of conversion for arithmetic, to ensure that poly_uint16 + poly_uint16 -> poly_int64 promotes before the addition rather than after it. But it defeats the point of the comparison warning, which is that you're potentially redefining the sign bit. I think the warning's just as valuable for may/must comparison of non-literals as it is for normal comparison operators. It's just unfortunate that we no longer get the special handling of literals. Thanks, Richard