From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23676 invoked by alias); 25 Aug 2017 15: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 23647 invoked by uid 89); 25 Aug 2017 15:26:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=investing, clunky, H*M:3526 X-HELO: mail-qt0-f178.google.com Received: from mail-qt0-f178.google.com (HELO mail-qt0-f178.google.com) (209.85.216.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Aug 2017 15:26:42 +0000 Received: by mail-qt0-f178.google.com with SMTP id q53so623341qtq.5 for ; Fri, 25 Aug 2017 08:26:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LFbG0zWQuLGjBF8lral8YW7mUh/ZSRgcajzMw/orSZc=; b=BjuI868uf7tyqzB3PkaqkprFSiaU/nXZ8Sufp+Mcayq6K/MSnQp3uDFnjEnhVhGEqp ILIToat1tMN6wrceIRCY8/78rHS0XghZWnvhw6b1jzVdtmNJSUi8hZfbwgMLkgUbGRKn ZAsC72hwASUzCSxr5QFgBrHKz/+ctJVz4K5ica95xmONv61121v3QQ2Hcl1UfX91V5G4 XLAKqwDg/jkYjfae4ux0qegHKRYj1pCR4+bdk8erqRUYp2RhhKY+v8zij4cfv5s6LgBU VNYw6TmC7VmV60fgAojdvwb2Vwti/mWRfNpD8uSY6Cb2Ac0zy4H/cS0UaRLTbOuOWubg KAmQ== X-Gm-Message-State: AHYfb5h2NIXgfrDSkuleZuJhnAkhvi0Z6I/746L0xYkOxDJnQN079zrd IxyxCytjCa8LCQ== X-Received: by 10.237.62.77 with SMTP id m13mr2421919qtf.74.1503674801268; Fri, 25 Aug 2017 08:26:41 -0700 (PDT) Received: from localhost.localdomain (174-16-125-25.hlrn.qwest.net. [174.16.125.25]) by smtp.gmail.com with ESMTPSA id 55sm4373738qtm.51.2017.08.25.08.26.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 08:26:40 -0700 (PDT) Subject: Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908) To: Richard Biener , Gcc Patch List , richard.sandiford@linaro.org References: <9143b5b4-e410-1c21-91e9-aa2a91b5ceeb@gmail.com> <87pobkf47r.fsf@linaro.org> From: Martin Sebor Message-ID: Date: Fri, 25 Aug 2017 16:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87pobkf47r.fsf@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01508.txt.bz2 > 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); 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. Martin