From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12930 invoked by alias); 26 Feb 2018 21:09:26 -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 12906 invoked by uid 89); 26 Feb 2018 21:09:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f182.google.com Received: from mail-wr0-f182.google.com (HELO mail-wr0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Feb 2018 21:09:23 +0000 Received: by mail-wr0-f182.google.com with SMTP id f14so22672882wre.8 for ; Mon, 26 Feb 2018 13:09:23 -0800 (PST) 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=Tx+Q1QbbfAX3fN1dt7OTQ9SUw9NHoUH5RoPd/xQ1rWQ=; b=LS7Skm+onc/a/aCjD25tKvMTXZWHeHCAn7hNfBMuCAsbjDVvGGunSi98FSOqenCd3V 6XYo5TA1IyyHScwZ0vksbs1knc7JK1l/8AyY4VcuFUuH6M4Sb2HpNaTEZBIsurSXXJNR nXmS7gxGF4WgvUN4ZOZcLP+3mAcTQ7ktXdYDSV58z7+5z37GGK1wsqmBd3Huev6Frpi2 U8Y8pY3Sj1zrnfKGQGzqMr+dvVyYSaPcsVJIBIkJO25SM7vqkoDwbu08DL4l25LjVRFZ fLXrgbDyZXpHtvEP4Rvd1NGSA6GG7+kxqWVAYaC4S+dT0VUkWyqboa4fKaO9Limr089I qBSA== X-Gm-Message-State: APf1xPCe8zdhuIsyVv8/wftp+BrSskyuehbxxwKrC5vVXvtsOstI5Y01 hQGjNMjyujw2ES6wFFlnsbQpaKHJtmU= X-Google-Smtp-Source: AH8x224q1uGPvO1yfbbYB5c+pcOALrnLX04iVPl1k8Qk3CxDxRM0e6JFJHZvce7c0gS5nstSoR35vQ== X-Received: by 10.223.170.211 with SMTP id i19mr11034581wrc.261.1519679361445; Mon, 26 Feb 2018 13:09:21 -0800 (PST) Received: from localhost (79.58.7.51.dyn.plus.net. [51.7.58.79]) by smtp.gmail.com with ESMTPSA id y64sm25955060wrb.56.2018.02.26.13.09.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Feb 2018 13:09:20 -0800 (PST) From: Richard Sandiford To: Martin Sebor Mail-Followup-To: Martin Sebor ,Gcc Patch List , richard.sandiford@linaro.org Cc: Gcc Patch List Subject: Re: [PATCH] expand description of poly_int conversions References: <8944eea9-f10b-f367-731a-39be7208e9e6@gmail.com> <87vaejh6wa.fsf@linaro.org> Date: Mon, 26 Feb 2018 21:09:00 -0000 In-Reply-To: (Martin Sebor's message of "Mon, 26 Feb 2018 13:19:55 -0700") Message-ID: <87r2p7h30g.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-02/txt/msg01465.txt.bz2 Martin Sebor writes: > On 02/26/2018 12:45 PM, Richard Sandiford wrote: >> Martin Sebor writes: >>> Richard, >>> >>> If you agree, I'd like to update the conversion section of >>> the poly_int manual to make the conversion to make it clearer >>> that the to_constant() function can be used even with class >>> types like offset_int besides scalars. >>> >>> Also, when testing this I also tried converting poly64_int >>> into wide_int but that doesn't work. Is there a way to do >>> that? >> >> Not in one go, because you have to specify the intended precision >> of the wide_int when constructing it from something like HOST_WIDE_INT. >> (That's deliberate.) >> >>> >>> Thanks >>> Martin >>> >>> gcc/ChangeLog: >>> >>> * doc/poly-int.texi (is_constant): Expand. >>> >>> Index: gcc/doc/poly-int.texi >>> =================================================================== >>> --- gcc/doc/poly-int.texi (revision 258004) >>> +++ gcc/doc/poly-int.texi (working copy) >>> @@ -836,9 +836,24 @@ Return true if @code{poly_int} @var{value} is a co >>> >>> @item @var{value}.is_constant (&@var{c1}) >>> Return true if @code{poly_int} @var{value} is a compile-time constant, >>> -storing it in @var{c1} if so. @var{c1} must be able to hold all >>> -constant values of @var{value} without loss of precision. >>> +storing it in @var{c1} if so. @var{c1} may be a scalar or a wide int >>> +class type capable of holding all constant values of @var{value} without >> >> Not sure about "a scalar or a wide int", since that implies that wide ints >> aren't scalar. Even more pedantic, sorry, but c1 is an object rather than >> a type. >> >> At a higher level, I'm a bit nervous about singling this out as a special >> case, since all the poly_int stuff allows HOST_WIDE_INT, offset_int and >> wide_int to be combined in the (hopefully) natural way. E.g. you can >> add offset_ints to poly_int64s, assign HOST_WIDE_INTs to poly_offset_ints, >> and so on. >> >> But if we do keep it like this, how about: >> >> @var{c1} must be some form of integer object that can hold all constant >> values of @var{value} without loss of precision; it can be either a normal >> C++ integer or a wide-int class like @code{offset_int}. >> >> ? > > Sure. Attached is an update with your change. LGTM (but I can't approve). Thanks, Richard