From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109711 invoked by alias); 25 Aug 2017 17:33:18 -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 109699 invoked by uid 89); 25 Aug 2017 17:33:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RCVD_IN_SORBS_WEB,SPF_PASS autolearn=no version=3.3.2 spammy=investing X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Aug 2017 17:33:16 +0000 Received: by mail-wm0-f47.google.com with SMTP id f13so2388198wme.1 for ; Fri, 25 Aug 2017 10:33:15 -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=5jw14RgMr8tQ5tCTbgV6tVm8ihBlly8imxxhzh/GtW8=; b=NironeTcyDj0s+YoGdm1Jx7duHkxi12wkjWMFPHcDDe1QhPCDkUu3nmkOiev7zGkni aCZBuIcjztrdBLSG9z9fpWS91R3gvtYZp56kxlAD+lQL/3mwHPi8134BVQQxbJsPGOXL UZ3qpGQ/C3LLahMNoBBZdO0Gcijth9IaH/V/DPkxCCOsb4IstkmQeGYQOB+v19L0KGzs lmK32CMliWnbw9++9zXXEQ2wxog6m3mejPHaWNtQyFq69lQyK/McCmH74ReAjppq9d73 ebtF9Ou9qJHkL5ioI/ctjjYgKg7QEriUMYGEEbfZAbnCq+iWitZ7gyr/4R/hkEX0KPCR 3fwg== X-Gm-Message-State: AHYfb5iWxdm7V+94+DmIxT6Ezegrj+QAQoRaal9jTgGRGUYpYlw5LKV9 bH6EpV4ow5Zyk9JVHFiHiw== X-Received: by 10.28.69.195 with SMTP id l64mr99821wmi.148.1503682394008; Fri, 25 Aug 2017 10:33:14 -0700 (PDT) Received: from localhost (92.40.248.75.threembb.co.uk. [92.40.248.75]) by smtp.gmail.com with ESMTPSA id o7sm6880551wra.39.2017.08.25.10.33.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 25 Aug 2017 10:33:13 -0700 (PDT) From: Richard Sandiford To: Martin Sebor Mail-Followup-To: Martin Sebor ,Richard Biener , Gcc Patch List , richard.sandiford@linaro.org Cc: Richard Biener , Gcc Patch List Subject: Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908) References: <9143b5b4-e410-1c21-91e9-aa2a91b5ceeb@gmail.com> <87pobkf47r.fsf@linaro.org> Date: Fri, 25 Aug 2017 18:13:00 -0000 In-Reply-To: (Martin Sebor's message of "Fri, 25 Aug 2017 09:26:39 -0600") Message-ID: <87k21rblig.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-08/txt/msg01521.txt.bz2 Martin Sebor writes: >> Just a stylistic thing, but since the only use of "wone" is in >> the eq_p, it'd be simpler just to use "1". Also, the maximum >> value is better calculated as "wi::max_value (prec, SIGNED)". So: >> >> /* Compute the value of SSIZE_MAX, the largest positive value that >> can be stored in ssize_t, the signed counterpart of size_t . */ >> wide_int ssize_max = wi::max_value (prec, SIGNED); >> >> return wi::eq_p (min, 1) && wi::geu_p (max, ssize_max); > > Thanks, I didn't know about the implicit conversion or the max_value > API. I'll remember to use them the next time. > > FWIW, going slightly off topic, and while I'm sure it's a matter > of getting used to the design, I can't say I find the wide_int > classes exactly intuitive. It seems that the most natural way > to write the return statement in C++ is: > > return min == 1 && max >= ssize_max; > > The first subexpression is accepted but the second one doesn't even > compile. If it did, it would treat the operands as signed which > isn't what I need here. One still has to resort to the clunky > predicate for it: > > return min == 1 && wi::geu_p (max, ssize_max); There are two main reasons for the wi:: stuff: 1. When we were adding wide-int initially, one of the requirements was that we could operate directly on rtx and tree representations of integers, without first converting them to wide_int etc. Since trees and rtxes are pointers, it wouldn't make sense to rely on operator overloading there. 2. wide_int itself has no inherent sign. (So I disagree with "If it did, it would treat the operands as signed which isn't what I need here." The reason for not having the overload is exactly that there is no obvious choice between signed and unsigned here.) And yes, Richard has been giving me grief about the lack of a wide_int-with-sign :-) > It also doesn't help that the names of the predicates don't follow > the same convention as those that operate on trees (e.g., eq_p vs > tree_int_cst_equal). > > Unless there's some inherent limitation that makes it impossible > to use the class the way I would like it might be worth investing > some time into making it more user-friendly. I think we already provide the overloads we can (i.e. those where the sign is known or isn't relevant). Let me know if we've missed some though. Thanks, Richard