From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24691 invoked by alias); 25 Oct 2017 16:59:59 -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 24675 invoked by uid 89); 25 Oct 2017 16:59:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=006 X-HELO: mail-oi0-f48.google.com Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com) (209.85.218.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Oct 2017 16:59:58 +0000 Received: by mail-oi0-f48.google.com with SMTP id w197so1157266oif.6 for ; Wed, 25 Oct 2017 09:59:57 -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=EVrPzYqjhWi2G599J2WSvotyIvlGHgiAPp1sYnOkeSE=; b=eQJwRtZRZticPgjaNbreKnlX1l/+YQ9zEBlOosLx9KdAcaoZ4/6Zoh5GvmI3v+27CK WcdOVmeyZtWylPxuAQrG3kyEYRb7ZheGimfTb+sCUzsNMjxt7Y0aJYit0yoNZn3w/YYw KdhQkqZEVrPPxKr9H+96+TqNs6SsOlyvgveUDUahxHcVdqefmcBGAkihcctfBP0/munG BhiyMZAH6aPdk0bhUnpqOWS1iMZaL/Gqi78ugDcqVX0Ham7NlEQwqZKdBDCs+o3HvPbb 8z3TRYAgfxSK6ccNLXmE1EMZZ/OA6s0VGiGqSZlQzh5RPZbAdbwJBEx03/Iq0vd2lT50 d2Pw== X-Gm-Message-State: AMCzsaXZiHqguYjAgeAuKQHmNx3GdHXdDVb8FbUdNI2lUta7E4Wsgf9T MuLBLE3PJ8tR176hEBIaTwk= X-Google-Smtp-Source: ABhQp+S/titkYu+BkYhYn49CXhMxH70y2Qd7b1xxIzMPSdgQ581X7MpXjwMx5l8UYInSANzYzq7Zhw== X-Received: by 10.202.178.133 with SMTP id b127mr1540034oif.261.1508950796282; Wed, 25 Oct 2017 09:59:56 -0700 (PDT) Received: from localhost.localdomain (71-218-5-6.hlrn.qwest.net. [71.218.5.6]) by smtp.gmail.com with ESMTPSA id a65sm1377353oih.45.2017.10.25.09.59.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 09:59:55 -0700 (PDT) Subject: Re: [006/nnn] poly_int: tree constants To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org References: <871sltvm7r.fsf@linaro.org> <878tg1u7cl.fsf@linaro.org> From: Martin Sebor Message-ID: Date: Wed, 25 Oct 2017 17:14: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: <878tg1u7cl.fsf@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg01828.txt.bz2 On 10/23/2017 11:00 AM, Richard Sandiford wrote: > +#if NUM_POLY_INT_COEFFS == 1 > +extern inline __attribute__ ((__gnu_inline__)) poly_int64 > +tree_to_poly_int64 (const_tree t) I'm curious about the extern inline and __gnu_inline__ here and not in poly_int_tree_p below. Am I correct in assuming that the combination is a holdover from the days when GCC was compiled using a C compiler, and that the way to write the same definition in C++ 98 is simply: inline poly_int64 tree_to_poly_int64 (const_tree t) > +{ > + gcc_assert (tree_fits_poly_int64_p (t)); > + return TREE_INT_CST_LOW (t); > +} If yes, I would suggest to use the C++ form (and at some point, changing the existing uses of the GCC/C idiom to the C++ form as well). Otherwise, if something requires the use of the C form I would suggest to add a brief comment explaining it. ... > + > +inline bool > +poly_int_tree_p (const_tree t, poly_int64_pod *value) > +{ ... > /* The tree and const_tree overload templates. */ > namespace wi > { > + class unextended_tree > + { > + private: > + const_tree m_t; > + > + public: > + unextended_tree () {} Defining no-op ctors is quite dangerous and error-prone. I suggest to instead default initialize the member(s): unextended_tree (): m_t () {} Ditto everywhere else, such as in: ... > template > class extended_tree > { > @@ -5139,11 +5225,13 @@ extern bool anon_aggrname_p (const_tree) > const_tree m_t; > > public: > + extended_tree () {} > extended_tree (const_tree); ... > Index: gcc/tree.c > =================================================================== ... > + > +/* Return true if T holds a polynomial pointer difference, storing it in > + *VALUE if so. A true return means that T's precision is no greater > + than 64 bits, which is the largest address space we support, so *VALUE > + never loses precision. However, the signedness of the result is > + somewhat arbitrary, since if B lives near the end of a 64-bit address > + range and A lives near the beginning, B - A is a large positive value > + outside the range of int64_t. A - B is likewise a large negative value > + outside the range of int64_t. All the pointer difference really > + gives is a raw pointer-sized bitstring that can be added to the first > + pointer value to get the second. */ I'm not sure I understand the comment about the sign correctly, but if I do, I don't think it's correct. Because their difference wouldn't representable in any basic integer type (i.,e., in ptrdiff_t) the pointers described above could never point to the same object (or array), and so their difference is not meaningful. C/C++ only define the semantics of a difference between pointers to the same object. That restricts the size of the largest possible object typically to SIZE_MAX / 2, or at most SIZE_MAX on the handful of targets where ptrdiff_t has greater precision than size_t. But even on those targets, the difference between any two pointers to the same object must be representable in ptrdiff_t, including the sign. > +bool > +ptrdiff_tree_p (const_tree t, poly_int64_pod *value) > +{ Martin