From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13079 invoked by alias); 10 May 2010 09:34:05 -0000 Received: (qmail 13065 invoked by uid 22791); 10 May 2010 09:34:04 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-yx0-f183.google.com (HELO mail-yx0-f183.google.com) (209.85.210.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 May 2010 09:34:00 +0000 Received: by yxe13 with SMTP id 13so2169953yxe.0 for ; Mon, 10 May 2010 02:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.179.5 with SMTP id b5mr7933244ybf.258.1273484036044; Mon, 10 May 2010 02:33:56 -0700 (PDT) Received: by 10.151.11.21 with HTTP; Mon, 10 May 2010 02:33:55 -0700 (PDT) In-Reply-To: <4EE7DEB362344819B080B47ED2A9E4DB@Vista> References: <1811669158.20100507225908@post.ru> <4EE7DEB362344819B080B47ED2A9E4DB@Vista> Date: Mon, 10 May 2010 09:34:00 -0000 Message-ID: Subject: Re: Remove build_int_cst_wide_type function. From: Richard Guenther To: Anatoly Sokolov Cc: gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2010-q2/txt/msg00016.txt.bz2 On Mon, May 10, 2010 at 11:24 AM, Anatoly Sokolov wrote: > Hi. > > ----- Original Message ----- From: "Richard Guenther" > > To: "Anatoly Sokolov" > Cc: ; > Sent: Saturday, May 08, 2010 12:31 AM > Subject: Re: Remove build_int_cst_wide_type function. > > >> Use build_int_cstu instead and retain using HOST_WIDE_INTs. =A0Btw, >> both build_int_cst and build_int_cstu should do proper sign/zero >> extension as the types precision may be lower than that of >> HOST_WIDE_INT. > > =A0The build_int_cst and build_int_cstu function don't clear extra bits > outside > of the type precision. The build_int_ct_type function truncate signed > HOST_WIDE_INT constant to the type precision. Comment before > build_int_cst_type > say: > /* ... =A0Constants > =A0with these extra bits may confuse the fold so that it detects overflows > =A0even in cases when they do not occur, and in general should be avoided. > =A0We cannot however make this a default behavior of build_int_cst without > =A0more intrusive changes, since there are parts of gcc that rely on the = extra > =A0precision of the integer constants. =A0*/ > > =A0Consequently, need both build_int_cst and build_int_cstu functions whi= ch > don't truncate constant and new build_int_cstu_type function which trunca= te > unsigned HOST_WIDE_INT constants. > > =A0How about rename build_int_cst_type/build_int_cstu_type function to > hwi_to_tree/uhwi_to_tree by analogy with the double_int_to_tree function? I don't think the comment is valid. The problem is that INTEGER_CSTs are shared and non-canonical ones should never be entered into the shared pool. Which means that build_int_cst_wide should assert that the constant is properly zero-/sign-extended according to its type (at least with ENABLE_CHECKING). Currently build_int_cst_wide is used as an optimization (to avoid the zero-/sign-extension when its already done), but really it is the low-level interface that shouldn't be exposed ... (we have way too many ways to build INTEGER_CSTs...) Richard. > Anatoly. >